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".
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
