My two cents: Given that Groovy 6 just got released and supports JDK 17, it makes sense to me that the next major version of Groovy would baseline against one "LTS" higher (scare quotes because, unless you're on a JDK vendor contract, LTS doesn't mean much). The MatchException advantage here is undisputed, so we have a reason to upgrade. So I don't really see a compelling "why not" here.
I tend to think that a more aggressive upgrade posture is the wiser course. My general sense is that more enterprises are building up steam to keep up with the Java release train. Those that don't can obviously continue on the last major version. If we could get to a place where the latest major Groovy release baselines against the latest Java LTS, I think that would be a good place to be. 21 would still be a step behind that, so it doesn't seem too aggressive to me. Best, Jonny On Fri, Sep 18, 2026 at 6:05 PM Paul King <[email protected]> wrote: > On Sat, Sep 19, 2026 at 5:46 AM Jochen Theodorou <[email protected]> > wrote: > > > > On 9/18/26 17:06, Daniel Sun wrote: > > > I'm inclined to support setting JDK 21 as the baseline for Groovy 7. A > few thoughts on why this strikes the right balance: > > > > > > 1) Cleaner GEP-19 integration: Standardizing on > java.lang.MatchException avoids synthetic exception shims or falling back > to IncompatibleClassChangeError. Jochen makes a very fair point about the > constraints of SwitchBootstraps in dynamic Groovy. However, for > @CompileStatic, having direct access to SwitchBootstraps.typeSwitch allows > us to emit standard invokedynamic bytecode instead of generating nested > instanceof cascades. > > > > For me the question is if we want to support isCase here or not. Records > > could have isCase, enums/class could have a static isCase - both even in > > static compilation. I have actually not checked if the last RC kept that. > > > > But yes... if we can make sure the switch has a specific form we can use > > that... I still think though we should look at the idea of these and > > then consider doing our own version to cover more cases. But if we spin > > our own version, we can also put these JDK bootstrapper behind our own > > bootstrap and call them depending on the JDK version. So even if we use > > them, we do not have to use them directly. > > > > As for MatchException. I am even in the unclear about how to properly > > use that exception properly and for more than reporting. So fail to say > > if a substitute exception (not error) is something to avoid beyond a > > mere "because Java does it so". > > As for MatchException, it is part "just" aligning with Java JEPs so we > don't need another entry in "Differences from Java", but also I think > a better warning for our users. If folks have code they run against an > Enum that has been recompiled with a new Enum value, I think ME would > be less puzzling than ICCE - though maybe Google/AI don't care much. > But for now I won't bump the version and see how far my explorations > go. As I will be on hols from today, I may not get to explore much now > anyway. > > Cheers, Paul. > > > > 2) Retiring dual-track runtime paths: Groovy 6 already serves JDK 17 > users well. Bumping to 21 allows us to drop compatibility fallbacks—such as > thread-pool fallbacks for virtual threads in async concurrency, or > redundant DGM dispatch logic overlapping with Sequenced Collections. > > > > virtual threads are opt-in in Groovy 6. And if we really want to always > > use virtual threads is a bit of an open question to me. > > The redundant dispatch logic in DGM you would have to explain to me > though. > > > > > 3) Pragmatic ecosystem pacing: JDK 25 is likely too aggressive for > mainstream enterprise adoption, while staying on JDK 17 would keep > unnecessary technical debt in the compiler. JDK 21 gives us a stable LTS > foundation without leaving most users behind. > > > > if with technical debt you mean the bootstrappers, then I do not agree. > > If you mean something else, please explain > > > > bye Jochen >
