As a heavy user of Groovy/Spock, though, I agree that upgrading Groovy itself can be challenging, unfortunately. Really depends though on how many edgy Groovy features you relied on :).
Not always for sure.
We started JDK upgrades with 9 and went +1 every half year and Groovy was lacking with one of 10, 11, 12 or 13. It got so tiring that we had to let it go.
Fortunately our tests were mostly JUnit 5, so it wasn't much of work.
If you're upgrading every minor Java version, then yeah, I agree Groovy and most other dependencies that may not work on Java version changes off the bat (Lambok, probably Spring and other heavy frameworks like Micronaut and Quarkus, build tools like Gradle... many more) are going to slow you down. You end up with a very simple project if you remove all of that, which is actually a good thing if you can afford doing it.
Those are not minor versions, that's quite natural path and is supported by every lib we used, except groovy. And this is the encouraged path for JDK upgrades, people are lazy, but not us :)
Spring supports new JDK release ("minor version" like you called them, those between 11 and 17 and 21) before release. The only exception was with JDK 13, there was about 2 week slip there.
Lombok (I don't like it) supports every such version at release (not before unfortunately).
Other libs didn't even error out (we keep them at newest versions possible, aside from Jakarta madness).
So from the major libs/frameworks, the only thing that slowed us down was groovy.
I see your point... I've never upgraded to the non-LTS Java versions (almost no one is doing it - as you can see in any survey about it - which in itself is enough for me not to be the "brave" one doing it!) so I don't know how much pain that would've been.
To me that just shows that Groovy could do with a bit more attention as I find it to be a great language, specially with Spock... it has made our tests so much nicer. It does have some warts but those are mostly a result of the lack of attention it receives, unfortunately, not some fundamental issues with the language.
It is a bit brave to upgrade every 6 releases or every 4, I prefer to have smaller issues more often than big ones rarely.
But I get that most of the time the issues is with dependencies that upgrade to lazily (that's why I don't like those that are bytecode magic and don't use ASM).
Kotlin, not Groovy, has been the culprit for slower Gradle support. I believe there was some split module pain in Groovy wrt Java 9, but it has been very smooth since then. The Kotlin compiler on the other hand is not very forgiving.
This is a moot point because your the build execution and the project compile/run can be on different JDKs. It is a tiny amount of configuration to decouple them, e.g. to use an EA build.
Yeah, you are right that decoupling build tool JDK and compile JDK is the way to go.
But Groovy does indeed not work, or has support very late for releases between 8, 11, 17 and 21 - so for anyone that wants to stay current (and not wait 3 or 2 years), using groovy in your code will be a pain - that might be also possible for other JVM languages, but I don't know, haven't used them.
Oh interesting. Typically the gradle release notes, like 8.4-rc-1, will have comments that imply that Groovy build scripts compile but Kotlin ones lag.
"Gradle now supports using Java 21 for compiling, testing, and starting other Java programs. This can be accomplished using toolchains. Currently, you cannot run Gradle on Java 21 because Kotlin lacks support for JDK 21. However, support for running Gradle with Java 21 is expected in future versions."
We ditched spock because of groovy, and never looked back. Now at jdk 21, previously at 20.