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
