Panama was delivered in JDK 19 and is final in JDK 23, out this March.

We don't give ETAs as people may make business decisions based on them. As a matter of policy, we only announce a targeted JDK within the 6 months prior to its release.

> it’s getting quite tedious to persuade everyone to keep it up and not jump ship, after getting burned by the previous JDK (and Spring) upgrades.

If nothing else, they should be placated by the fact that upgrades are significantly worse in every other ecosystem.

> If nothing else, they should be placated by the fact that upgrades are significantly worse in every other ecosystem.

A lot of ecosystems care about their users and care about compatibility. Java is a toxic relationship at this point.

I think that Java's record on compatibility is unmatched, and users are extremely happy with all the enhancements we've been delivering, which why Java's popularity remains sky-high. But no product can satisfy everyone forever, and if you're unhappy, we'd like to try and address the issues you have; if we can't, we'd be sad to see you go, but we certainly don't wish to hold you hostage.

Yes, absolutely, Java’s compatibility story has been stellar. To the point that people got spoiled by it and no longer want to join the more agile release cycle. I’ve experienced folks being more like “oh finally, now I can express myself at least a bit like I got used to with some other language”, so not sure the enhancements you’re mentioning go as far as to put Java apart from its modern day alternatives, at least some of those concepts finally trickled through though. Still, a lot of Java deployments are deliver once, never touch it again, those users would be happy to never upgrade anything. It’s no fun to revalidate the semantics in a large project.

> those users would be happy to never upgrade anything. It’s no fun to revalidate the semantics in a large project.

Yep, that's why we introduced the LTS service. People may not have noticed before we did away with major releases and changed the version naming scheme, but in the past you had no choice but to upgrade to semi-annual releases with major VM changes, like 8u20 or 7u4 (probably because the name was too similar to patch releases, like 8u30 or 7u5). Now, with LTS, we try to only backport security patches and major bug fixes to make sure that such legacy users get the stability they need.

Gradle is still at JDK 21, albeit not comprehensively as it sometimes still fails to build on anything more recent than JDK 20. Most projects haven’t transitioned to JDK 17 yet. There’s a gap already. I don’t really want to draw parallels but Scala 2 to 3 wasn’t supposed to go the way Python had gone, everyone was certain that wouldn’t be the case, while .NET made a clear cut and somehow managed to move everyone forward, perhaps because of the monocentric organization of the ecosystem. From my experience, I can’t relate with your last sentence however. I do totally appreciate your efforts and investment into the Java community Ron, always have, but your words now feel like a disconnect, or perhaps I am simply no longer part of your target audience.

I don't understand what you're trying to say. Python's migration has clearly been worse and took longer, .NET break their users every 6-7 years on average requiring significant rewrites (except .NET's users have been used to that pain for many years and accept it clear-eyed), and the JS ecosystem is such a mess that people rewrite their programs every couple of years because their libraries keep being abandoned or make incompatible changes as a matter of habit.