You are viewing a plain text version of this content. The canonical link for it is here.
Posted to announce@apache.org by Paul King <pa...@apache.org> on 2025/08/06 10:54:01 UTC
[ANNOUNCE] Apache Groovy 5.0.0-rc-1 Released!
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 the https://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 at https://groovy.apache.org/
Best regards,
The Apache Groovy team.
Re: [ANNOUNCE] Apache Groovy 5.0.0-rc-1 Released!
Posted by Paul King <pa...@asert.com.au>.
Thanks to everyone who has contributed!
On Wed, Aug 6, 2025, 10:05 PM Søren Berg Glasius <so...@glasius.dk> wrote:
> Congratulations on releasing the future of Groovy!
>
> Den ons. 6. aug. 2025 kl. 12.54 skrev Paul King <pa...@apache.org>:
>
>> 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 the https://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 at https://groovy.apache.org/
>>
>> Best regards,
>>
>> The Apache Groovy team.
>>
>
>
> --
>
> Med venlig hilsen,
> Søren Berg Glasius
>
> Hedevej 1, Gl. Rye, 8680 Ry
> Mobile: +45 40 44 91 88
> --- Press ESC once to quit - twice to save the changes.
>
Re: [ANNOUNCE] Apache Groovy 5.0.0-rc-1 Released!
Posted by Søren Berg Glasius <so...@glasius.dk>.
Congratulations on releasing the future of Groovy!
Den ons. 6. aug. 2025 kl. 12.54 skrev Paul King <pa...@apache.org>:
> 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 the https://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 at https://groovy.apache.org/
>
> Best regards,
>
> The Apache Groovy team.
>
--
Med venlig hilsen,
Søren Berg Glasius
Hedevej 1, Gl. Rye, 8680 Ry
Mobile: +45 40 44 91 88
--- Press ESC once to quit - twice to save the changes.
Re: Groovy 5 - Performance / @CompileStatic
Posted by MG <mg...@arscreat.com>.
Hi Jochen,
1. I read your post multiple times, and after overcoming the initial
"How complicated is this, I thought the indy mechanism was supposed
to take care of that... ?" reaction of my brain ( ;-) ), I think I
can approximately follow what you were suggesting in broad strokes.
2. However "We have to keep the cost of (indy) initialization much
lower than we do right now" definitely gets my prize for the
TLDR/executive version ;-)
3. I just saw Eric offered to help with a potential prototype, which
would be great - maybe Grooyv indy will one day be as fast as its
non-indy counterpart, even under heavy stress... G-)
Cheers,
mg
Am 13.08.2025 um 21:28 schrieb Jochen Theodorou:
> I think it is the cost of initialization. We have to keep that much
> lower than we do right now. Sadly you are the only reacting to that
> mail so far. I thought I kept it simple enough...
Re: Groovy 5 - Performance / @CompileStatic
Posted by Jochen Theodorou <bl...@gmx.org>.
On 16.12.25 17:42, James Daugherty wrote:
> Hi Everyone,
>
> This performance issue was recently brought up as a Grails ticket
> (https://github.com/apache/grails-core/issues/15293). We haven't
> switched to Groovy 5 yet, but it would be nice if we could improve the
> performance prior to switching. Was any progress ever made on this
> thread? @Jochen & @Miles?
afaik none
Maybe I will find some time around xmas, but no promises
bye Jochen
Re: Groovy 5 - Performance / @CompileStatic
Posted by James Daugherty <jd...@apache.org>.
Hi Everyone,
This performance issue was recently brought up as a Grails ticket
(https://github.com/apache/grails-core/issues/15293). We haven't
switched to Groovy 5 yet, but it would be nice if we could improve the
performance prior to switching. Was any progress ever made on this
thread? @Jochen & @Miles?
The user was kind enough to include a test application with Grails 7
to help research these performance issues. From their research they
indicated the slow downs were mostly in Groovy code. Unfortunately,
the application is for Groovy 4 since Grails isn't on Groovy 5 yet.
(We still don't have Groovy 5 compiling with Grails and are gradually
opening tickets / working on these as we can in this PR chain
https://github.com/apache/grails-core/pull/15183).
-James
On Thu, Aug 21, 2025 at 11:55 AM MG <mg...@arscreat.com> wrote:
>
> Hi Jochen,
>
> since, as I said, we could not pinpoint any specific, smaller piece of code that exhibits the problem, we can alas not supply a test case.
> But if you guys want to try out this 80% (?) quick fix solution, I can offer to test it with our framework, as soon as we have successfully switched to Groovy 5.
>
> Cheers,
> mg
>
>
> Am 14.08.2025 um 09:38 schrieb Jochen Theodorou:
>
> That would be very much appreciated. My problem is a bit the "where to start while having something real life testable"
>
> and maybe something like
>
> callsite.paths = [SLOW_PATH_0, current logic]
> callsite.counter = 0
>
> callsite target = {
> if (counter < THRESHOLD) {
> increase counter
> continue with paths[0]
> } else {
> continue with paths[1]
> }
> }
>
> as a first step would already help a bit and would be near the final solution I drafted in my mail as well
>
> bye Jochen
>
> On 13.08.25 22:11, Milles, Eric (TR Technology) via dev wrote:
>
> I have been following the discussion. Jochen, if you want to work together on a prototype for this, I can surely help.
>
> ------------------------------------------------------------------------
> *From:* Jochen Theodorou <bl...@gmx.org>
> *Sent:* Wednesday, August 13, 2025 2:28 PM
> *To:* dev@groovy.apache.org <de...@groovy.apache.org>
> *Subject:* [EXT] Re: Groovy 5 - Performance / @CompileStatic
> External Email: Use caution with links and attachments.
>
> On 10.08.25 22:59, MG wrote:
> [...]
>
> 3. But, most importantly, as Jochen stated in his last reply: "Yes, in
> the end MethodHandles are faster, but only once optimizations have
> run. /And that takes thousands of iterations/. MG for example has
> been hit by this."
> 1. So he thinks he already knows what causes the performance
> degradation when using Groovy indy, and already points out some
> way(s) to improve this (independent of the specifics our project)...
>
>
> I think it is the cost of initialization. We have to keep that much
> lower than we do right now. Sadly you are the only reacting to that mail
> so far. I thought I kept it simple enough...
>
> bye Jochen
>
>
>
Re: Groovy 5 - Performance / @CompileStatic
Posted by MG <mg...@arscreat.com>.
Hi Jochen,
1. since, as I said, we could not pinpoint any specific, smaller piece
of code that exhibits the problem, we can alas not supply a test case.
2. But if you guys want to try out this 80% (?) quick fix solution, I
can offer to test it with our framework, as soon as we have
successfully switched to Groovy 5.
Cheers,
mg
Am 14.08.2025 um 09:38 schrieb Jochen Theodorou:
> That would be very much appreciated. My problem is a bit the "where to
> start while having something real life testable"
>
> and maybe something like
>
> callsite.paths = [SLOW_PATH_0, current logic]
> callsite.counter = 0
>
> callsite target = {
> if (counter < THRESHOLD) {
> increase counter
> continue with paths[0]
> } else {
> continue with paths[1]
> }
> }
>
> as a first step would already help a bit and would be near the final
> solution I drafted in my mail as well
>
> bye Jochen
>
> On 13.08.25 22:11, Milles, Eric (TR Technology) via dev wrote:
>> I have been following the discussion. Jochen, if you want to work
>> together on a prototype for this, I can surely help.
>>
>> ------------------------------------------------------------------------
>> *From:* Jochen Theodorou <bl...@gmx.org>
>> *Sent:* Wednesday, August 13, 2025 2:28 PM
>> *To:* dev@groovy.apache.org <de...@groovy.apache.org>
>> *Subject:* [EXT] Re: Groovy 5 - Performance / @CompileStatic
>> External Email: Use caution with links and attachments.
>>
>> On 10.08.25 22:59, MG wrote:
>> [...]
>>> 3. But, most importantly, as Jochen stated in his last reply:
>>> "Yes, in
>>> the end MethodHandles are faster, but only once optimizations have
>>> run. /And that takes thousands of iterations/. MG for example has
>>> been hit by this."
>>> 1. So he thinks he already knows what causes the performance
>>> degradation when using Groovy indy, and already points out
>>> some
>>> way(s) to improve this (independent of the specifics our
>>> project)...
>>
>> I think it is the cost of initialization. We have to keep that much
>> lower than we do right now. Sadly you are the only reacting to that mail
>> so far. I thought I kept it simple enough...
>>
>> bye Jochen
>>
>
Re: Groovy 5 - Performance / @CompileStatic
Posted by Jochen Theodorou <bl...@gmx.org>.
That would be very much appreciated. My problem is a bit the "where to
start while having something real life testable"
and maybe something like
callsite.paths = [SLOW_PATH_0, current logic]
callsite.counter = 0
callsite target = {
if (counter < THRESHOLD) {
increase counter
continue with paths[0]
} else {
continue with paths[1]
}
}
as a first step would already help a bit and would be near the final
solution I drafted in my mail as well
bye Jochen
On 13.08.25 22:11, Milles, Eric (TR Technology) via dev wrote:
> I have been following the discussion. Jochen, if you want to work
> together on a prototype for this, I can surely help.
>
> ------------------------------------------------------------------------
> *From:* Jochen Theodorou <bl...@gmx.org>
> *Sent:* Wednesday, August 13, 2025 2:28 PM
> *To:* dev@groovy.apache.org <de...@groovy.apache.org>
> *Subject:* [EXT] Re: Groovy 5 - Performance / @CompileStatic
> External Email: Use caution with links and attachments.
>
> On 10.08.25 22:59, MG wrote:
> [...]
>> 3. But, most importantly, as Jochen stated in his last reply: "Yes, in
>> the end MethodHandles are faster, but only once optimizations have
>> run. /And that takes thousands of iterations/. MG for example has
>> been hit by this."
>> 1. So he thinks he already knows what causes the performance
>> degradation when using Groovy indy, and already points out some
>> way(s) to improve this (independent of the specifics our project)...
>
> I think it is the cost of initialization. We have to keep that much
> lower than we do right now. Sadly you are the only reacting to that mail
> so far. I thought I kept it simple enough...
>
> bye Jochen
>
Re: Groovy 5 - Performance / @CompileStatic
Posted by "Milles, Eric (TR Technology) via dev" <de...@groovy.apache.org>.
I have been following the discussion. Jochen, if you want to work together on a prototype for this, I can surely help.
________________________________
From: Jochen Theodorou <bl...@gmx.org>
Sent: Wednesday, August 13, 2025 2:28 PM
To: dev@groovy.apache.org <de...@groovy.apache.org>
Subject: [EXT] Re: Groovy 5 - Performance / @CompileStatic
External Email: Use caution with links and attachments.
On 10.08.25 22:59, MG wrote:
[...]
> 3. But, most importantly, as Jochen stated in his last reply: "Yes, in
> the end MethodHandles are faster, but only once optimizations have
> run. /And that takes thousands of iterations/. MG for example has
> been hit by this."
> 1. So he thinks he already knows what causes the performance
> degradation when using Groovy indy, and already points out some
> way(s) to improve this (independent of the specifics our project)...
I think it is the cost of initialization. We have to keep that much
lower than we do right now. Sadly you are the only reacting to that mail
so far. I thought I kept it simple enough...
bye Jochen
Re: Groovy 5 - Performance / @CompileStatic
Posted by Jochen Theodorou <bl...@gmx.org>.
On 10.08.25 22:59, MG wrote:
[...]
> 3. But, most importantly, as Jochen stated in his last reply: "Yes, in
> the end MethodHandles are faster, but only once optimizations have
> run. /And that takes thousands of iterations/. MG for example has
> been hit by this."
> 1. So he thinks he already knows what causes the performance
> degradation when using Groovy indy, and already points out some
> way(s) to improve this (independent of the specifics our project)...
I think it is the cost of initialization. We have to keep that much
lower than we do right now. Sadly you are the only reacting to that mail
so far. I thought I kept it simple enough...
bye Jochen
Re: Groovy 5 - Performance / @CompileStatic
Posted by MG <mg...@arscreat.com>.
Hi Daniel,
1. due to the nature of our org it would alas be very hard to
impossible to supply a meaningful flame graph at this point.
1. We also did invest quite a bit of time and effort to create a
cleaned standalone example of the problematic code parts (still
quite a large part of our project) the last time around, and
that alas did not lead to any performance improvements on the
Groovy side.
2. Also, as I already said, it looks like Groovy is "loosing
performance everywhere", so we are not sure if supplying the graph
would help, even in principle.
3. But, most importantly, as Jochen stated in his last reply: "Yes, in
the end MethodHandles are faster, but only once optimizations have
run. /And that takes thousands of iterations/. MG for example has
been hit by this."
1. So he thinks he already knows what causes the performance
degradation when using Groovy indy, and already points out some
way(s) to improve this (independent of the specifics our project)...
Cheers,
mg
Am 08.08.2025 um 17:54 schrieb Daniel Sun:
> Could you please provide some flame graphs to help us address the performance issue you mentioned.
>
> Cheers,
> Daniel Sun
>
> On 2025/08/07 19:24:29 MG wrote:
>> 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.
Re: Groovy 5 - Performance / @CompileStatic
Posted by Daniel Sun <su...@apache.org>.
Could you please provide some flame graghs to help us address the performance issue you mentioned.
Cheers,
Daniel Sun
On 2025/08/07 19:24:29 MG wrote:
> 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.
>
Re: Groovy 5 - Performance / @CompileStatic
Posted by Jochen Theodorou <bl...@gmx.org>.
On 07.08.25 21:24, MG wrote:
> 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.
[...]
I have a long list of changes to be done to the invokedynamic code. The
simple problem is that invokedynamic is complex and difficult to handle.
And because of context switching I never found a window big enough to
actually do the changes I have in mind. Then I wanted to write a
document explaining all the problems so that maybe others can do it...
but that turned out to be still too much so far.
bye Jochen
Groovy 5 - Performance / @CompileStatic
Posted by MG <mg...@arscreat.com>.
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.
Groovy 5 - Performance / @CompileStatic
Posted by MG <mg...@arscreat.com>.
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.