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. 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. 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. Just my two cents—curious to hear what others think. Cheers, Daniel Sun On 2026/09/18 00:27:45 Paul King wrote: > Hi folks, > > Now that master is on version 7, we need to decide on the minimum > supported JDK version. This is the *minimum* version not the *maximum* > version, so we can always use newer features in later versions if we > need. Our VMPlugin already supports that, and we have a history of > supporting Java (or Java-like) features on earlier JDKs. > > We tend to be conservative with this choice because it can exclude > many users from adopting our new versions, but we also sometimes > benefit from later JDK features. In Groovy 7, we plan to look at > GEP-19 (more advanced switch pattern matching), so some of the JDK21 > work in that space (like having MatchException and SwitchBootstraps) > would be really beneficial. I propose bumping the minimum to 21 for > that reason. I don't know of any JDK 25 features we need just yet, but > if we find any, we can always bump the minimum again later. > > I'd be keen to hear others' thoughts. > > Cheers, Paul. >
