grabbit
grabbit copied to clipboard
TWCable
Migrate from Groovy to Java 8
In addition to removing yet-another potential library dependency conflict (per #105), Grabbit would benefit from the additional performance and type-safety, per some of the changes made in grabbit-cli.
A proposed list of steps:
- [ ] Initial build-file changes for move to Java 8 : GH-126
- [ ] Convert "low hanging fruit" from Groovy to Java : GH-127
- [ ] Implement high-priority new changes in Java instead of Groovy : no ticket as this is more a planning approach...
- [ ] Finish off the translation for the remaining classes : GH-128
- [ ] Remove dependencies and build steps related to Groovy : GH-129
Can we get the same benefits by incorporating just the Java 8 runtime?
Would we gradually start incorporating Java 8 language features with new additions?
The runtime itself (i.e., JRE 1.8) is better performance and reliability, but that happens as a deployment concern for AEM. This is about taking advantage of the Java 8 language features and surrounding tooling (such as Checker Framework, static analysis, etc.).
The Groovy language is geared toward being dynamic, and even with the @CompileStatic it still doesn't match the Java in those aspect. Prior to Java 8, it was well worth it, but that's a much harder case to make now.
One obvious implication that should be made explicit is that it means that once the change is made it will only work on AEM 6.1+ running on JRE 1.8+. Since Grabbit v4+ is AEM 6.1 anyway, I don't think that's a problem in any way, but best to be very clear.
Hmm, okay. I'm still a bit confused on what problem we are trying to solve by doing this though. I'm not aware of any predominantly JVM-related performance issues we are currently running into.
PMD, and Checker might be nice; but introducing all these changes at once seems an unnecessarily high risk to value-add proposition.
It's far more a design/correctness thing than performance (which is primarily I/O-bound). While a LOT more static analysis isn't going to solve all problems, it certainly helps drive much better code.
Sagar, you, Masroor, etc write really good stuff, but I know there's only so much my poor little brain can handle. The more I can off-load to the computer to do for me, the better everyone's life is. Add to that this being open-source, the lower the barrier-to-entry is for others to contribute (more people know Java than Groovy) and the more guardrails we can put up for validating quality automatically before it even hits code-review... Well, again, the better everyone's life is.
As to "at once" --- that's why it's broken down into multiple stages. Fortunately, since Grabbit was written TDD, there's a lot of support to keep such mechanical transformations in line.
Now, once this is done, there's some much more ambitious things I'd like to see. But one thing at a time. 🚶