[brabel]

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.

[krzyk]

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.

[brabel]

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.

[krzyk]

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