Hi .+,
since Groovy 5 to my knowledge is the first Groovy which does away with
the old, faster, non-invoke-dynamic call site resolution support, I
wanted to do a quick post on that topic that might be of interest to
larger Groovy projects like ours:
1. After the initial performance problems in Groovy 3/4 caused
by invoke-dynamic, for which we were, with some effort, in the end
able to pinpoint the culprit in our code and implement a workaround,
we unfortunately discovered another performance drop in a later
Groovy version.
1. The drop was less severe than in the previous case, but was
around a factor of 2 when it appeared.
2. In this case we were alas not able to find a specific code part that
caused the drop in performance, but it seemed like Groovy was
leaking a bit of performance on every level, which in the end added
up to our main web application running with half speed in certain
crucial parts, as well as our test suite taking far longer to
execute fully.
3. After posting about this on the mailing list we initially waited
whether Groovy invoke-dynamic performance would improve, but over
time it became clear that that would most likely not be the case.
4. Faced with this, we had several options:
1. Stay on Groovy 4 with non-invoke-dynamic enabled for the
foreseeable future.
2. Try if switching to statically compiled Groovy (@CompileStatic)
would solve our performance woes.
3. Switch (at least partially) to a different JVM language.
5. Since we neither wanted to be locked into Groovy 4 forever (for
obvious reasons), and Groovy is our language of choice (for obvious
reasons ;-) ), the only real option was trying the @CompileStatic route.
6. Unfortunately we:
1. Knew from prior experiences that one cannot just
add @CompileStatic to every class in a project and expect the
code to compile / run as expected.
2. Had decided to switch from @CompileStatic to @TypeChecked a
while ago, to get the benefits of dynamic calls site resolution
(while still having compile time checking).
7. So, since just auto-applying @CompileStatic to our whole project was
not feasible, we used a more selective approach, where we only
auto-apply @CompileStatic to a single one of our modules at a time.
1. Simple groovyConfig source to achieve that below (feel free to
include verbatim in your project).
1. Note: If there is already a
CompileStatic/CompileDynamic/TypeChecked annotation on the
class it will be skipped.
2. If you want to cook your own and you use your own Groovy macros,
be aware that your Groovy macro module must be excluded in any
case, or you will get some weird, hard to pinpoint build errors!
8. We started with the lowest of our library modules, working our way
up in the dependency chain.
1. In our case that was groovyutil (basic shared functionality),
and then groovysql (SQL objects, query building & schema
evolution functionality).
2. Both modules took a few days each to compile
under @CompileStatic & all tests to be green.
9. Given the speed at which we progressed, turning our whole
project @CompileStatic would have probably taken a month or so.
10. Luckily our bottom up approach paid off, and once the groovysql
module was done, performance was indistinguishable
between invoke-dynamic and non-invoke-dynamic builds! :-)
1. I might do a follow up "tips / lessons learned" post, as time
allows...
11. Thanks go out to the Groovy dev(s) who are constantly working to
improve @CompileStatic support: Partially switching
to @CompileStatic would definitely have been more hassle a few years
back! G-)
Cheers,
mg
import groovy.transform.CompileDynamic
import groovy.transform.CompileStatic
import groovy.transform.TypeChecked
import org.codehaus.groovy.ast.AnnotationNode
import org.codehaus.groovy.control.customizers.ASTTransformationCustomizer
import org.codehaus.groovy.control.customizers.SourceAwareCustomizer
import org.codehaus.groovy.ast.ClassNode
import java.lang.annotation.Annotation
/
// Enable invoke-dynamic (indy) usage/
configuration.optimizationOptions.indy = true
/
// Auto @CompileStatic/
final hasModuleCls = *{ *ClassNode n, List<String> moduleNames *->
*if(n.packageName === null) { return false }
final packagePathElements = n.packageName.split(/\./)
moduleNames.any *{ *String moduleName *->
*packagePathElements.contains(moduleName) *}
}
*
final hasAnyAnnotationCls = *{ *ClassNode n, List<Class<Annotation>>
annotations *-> *n.annotations.any *{ *AnnotationNode an *->
*an.classNode.class in annotations *} }
*
final compileStaticModules = ['groovyutil', 'groovysql']
final skipModules = ['groovymacro']
final autoCompileStatic = new SourceAwareCustomizer(new
ASTTransformationCustomizer(CompileStatic))
autoCompileStatic.setClassValidator *{ *ClassNode n *->
*!hasModuleCls(n, skipModules) && hasModuleCls(n, compileStaticModules)
&& !hasAnyAnnotationCls(n, [CompileStatic, CompileDynamic, TypeChecked]) *}*
configuration.addCompilationCustomizers(autoCompileStatic)
Am 06.08.2025 um 12:54 schrieb Paul King:
Dear community,
The Apache Groovy team is pleased to announce version 5.0.0-rc-1 of
Apache Groovy.
Apache Groovy is a multi-faceted programming language for the JVM.
Further details can be found at thehttps://groovy.apache.org website and in the
Groovy 5 release notes:https://groovy-lang.org/releasenotes/groovy-5.0.html
This is a pre-release of a new version of Groovy.
We greatly appreciate any feedback you can give us when using this version.
This release includes 9 bug fixes/improvements as outlined in the changelog:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318123&version=12356146
Sources, convenience binaries, downloadable documentation and an SDK
bundle can be found at:https://groovy.apache.org/download.html
We recommend you verify your installation using the information on that page.
Jars are also available within the major binary repositories.
We welcome your help and feedback and in particular want
to thank everyone who contributed to this release.
For more information on how to report problems, and to get involved,
visit the project website athttps://groovy.apache.org/
Best regards,
The Apache Groovy team.
