My expectation is (and anyone please correct me if you think differently): * 17 is the minimum we can target in the bytecode * 17 is the minimum for tools like groovy, groovyc, groovysh, groovyConsole * 17 is the minimum runtime for compiled code * we can use anything up to JDK17 in the Groovy source code and generated bytecode, e.g. Stream#toList is JDK16+ for instance, records, nest changes, invokeXXX opcode improvements, etc.
The build itself might need a later version to compile plugin extensions if we introduce any (none yet). Cheers, Paul. On Mon, Aug 25, 2025 at 11:57 PM Milles, Eric (TR Technology) via dev < dev@groovy.apache.org> wrote: > Does minimum [Java] version refer to the runtime the tools require or the > JVM that we can target? I think Java 17 is a sensible minimum for Groovy > 6. With Groovy 5 supporting Java 11 and Groovy 4 supporting Java 8. > > ------------------------------ > *From:* Christopher Smith <chrylis+gro...@gmail.com> > *Sent:* Sunday, August 24, 2025 7:29 AM > *To:* dev@groovy.apache.org <dev@groovy.apache.org> > *Subject:* [EXT] Re: [DISCUSS] Minimum version for Groovy 6 > > *External Email:* Use caution with links and attachments. > I'm at a very small startup, and we still haven't migrated past Java 11, > simply because there were some bugs in some libraries we used with 17, and > we only have one and a half people working on the backend. We're planning > to leapfrog to 25 when it's released, so we need *support* for > compiling/running on 25, but 17 as a baseline makes it much more sense to > me. > > One task I'd like to work on for Groovy 6 (hoped for 5 but just haven't > had the bandwidth) is an update of the signatures for the GDK extension > methods to support JDK functional interfaces in addition to, and perhaps > eventually partly instead of, Closure. `with`, for example, has magical > properties for a closure's delegate, so perhaps it always keeps that > overload, but it's frustrating not being able to invoke it with a library > Function without a bunch of extra overhead. > > Christopher Smith > > On Sun, Aug 24, 2025, 07:07 Guillaume Laforge <glafo...@gmail.com> wrote: > > I also like the idea of going with 17. > Of course, we don't yet really know when Groovy will be released, but it > sounds like a safe version to base it on, without cutting with users who > may not have migrated beyond 17. > > > > *Guillaume Laforge* > Apache Groovy committer > Developer Advocate @ Google Cloud > <https://urldefense.com/v3/__https://cloud.google.com/__;!!GFN0sa3rsbfR8OLyAw!fLFWFBnOph9gaBqWJqBVKKhaaYsWZUlH9X4b1q-0h7RZ7BYPTu3NtDhBpoDjreOpEGbZCff8KVLN_Kt4TyM0SJIE_lSlpZg$> > > - Blog: glaforge.dev > > <https://urldefense.com/v3/__http://glaforge.dev/__;!!GFN0sa3rsbfR8OLyAw!fLFWFBnOph9gaBqWJqBVKKhaaYsWZUlH9X4b1q-0h7RZ7BYPTu3NtDhBpoDjreOpEGbZCff8KVLN_Kt4TyM0SJIEw3OGYxM$> > - X: @glaforge > > <https://urldefense.com/v3/__http://twitter.com/glaforge__;!!GFN0sa3rsbfR8OLyAw!fLFWFBnOph9gaBqWJqBVKKhaaYsWZUlH9X4b1q-0h7RZ7BYPTu3NtDhBpoDjreOpEGbZCff8KVLN_Kt4TyM0SJIE0Ntj4XY$> > - Bluesky: @glaforge.dev > > <https://urldefense.com/v3/__https://bsky.app/profile/glaforge.dev__;!!GFN0sa3rsbfR8OLyAw!fLFWFBnOph9gaBqWJqBVKKhaaYsWZUlH9X4b1q-0h7RZ7BYPTu3NtDhBpoDjreOpEGbZCff8KVLN_Kt4TyM0SJIEInEQs_Y$> > - Mastodon: @glafo...@uwyn.net > > <https://urldefense.com/v3/__http://*40glafo...@uwyn.net/__;JQ!!GFN0sa3rsbfR8OLyAw!fLFWFBnOph9gaBqWJqBVKKhaaYsWZUlH9X4b1q-0h7RZ7BYPTu3NtDhBpoDjreOpEGbZCff8KVLN_Kt4TyM0SJIE2VqbkEg$> > > > Le dim. 24 août 2025, 12:58, Andres Almiray <aalmi...@gmail.com> a écrit : > > Sounds doable, considering that Maven 4 will also use Java 17. > > They have long discussed whether jumping to 21 should be the case as they > want to support the last 2 LTS. With Java 25 coming closer (next month) > there's a group pushing for jumping to 21. > In our case I think staying with 17 is OK. > > Cheers, > Andres > > On Sun, Aug 24, 2025 at 12:44 PM Paul King <pa...@asert.com.au> wrote: > > > Hi folks, > > Now that 5 is out, I created a GROOVY_5_0_X branch, and master has become > Groovy 6. > > We should discuss a minimum JDK version we plan to support for Groovy 6. > > My current thinking is that since we are typically very conservative with > the minimum version, we should bump to JDK17. I am hoping Groovy 6 will be > delivered with a quicker window than Groovy 5, but there hasn't been any > discussion about features as yet, so it's a little hard to predict. I think > JDK17 gives us a nice increment where we can make numerous advances, and if > the release is taking longer than we expected, we can always adjust our > decision. But, I'm interested in what others think ... > > > > Cheers, Paul. > >
