On Gradle 8.5-rc-3 Release Notes I read:
The following plugins were fully converted to Java: jacoco, scala, osgi, javascript, distribution and announce.
Some other plugins were partially converted to Java, keeping tasks types as Groovy classes: init, checkstyle, codenarc, findbugs, pmd, jdepend, java, war, ear, application, signing, comparison, idea and eclipse. For the latter two, plugin types have also been kept in Groovy.
Out of curiosity, why did this happen?
Mauro
The Gradle code base is already primarily Java (GitHub numbers are misleading as almost all Groovy is test code). Dynamic Groovy code incurs a performance penalty, primarily due to dynamic dispatch and exception-based flow control. In many cases we didn’t actually convert to Java, we simply leveraged @CompileStatic to statically compile our Groovy code. The effective outcome is the same. Basically, the motivation was not to remove Groovy from the Gradle codebase, the goal was to remove dynamic code, whether that be by converting to Java or statically-typed Groovy.
I asked my question just because I’m also currently wondering whether I should still bet on Groovy for my own business projects or not, given the current really uncertain and unstable state of Groovy tooling for Eclipse, which is our IDE of choice. Of course Groovy is still valuable for things like scripting in Gradle, but my doubt is about its use in our own application and library classes…
My curiosity was because given the existence of @CompileStatic, I was wondering whether there was just a performance reason behind the choice of converting code to Java (which is a something I’m also doing sometimes, but for other reasons, as said).
So, thanks for sharing this Mark!
Mauro
Sorry to interject in the conversation. My personal opinion on this is to use Java for the plugin model/business logic and use Groovy for configuration of the model. The reason is mainly that Java is more explicit which make it easier to maintain in the future but will have more code to write. The configuration in Groovy enable to shortcut some syntax and make it easier to read, mainly because of the closure syntax. Those are the guidelines we have been moving forward with.