[Freak_NL]

Ideally, yes. In the real world? Nope. The longer you work one some project, the bigger the chance you will run into some edge case determined by the major version of the JDK. It just happens.

Even if you do all developing on the latest LTS, you will want to be able to switch to whatever version is running on the dev or prod application servers to replicate a bug as closely as possible.

By the way, you are ignoring the case I mentioned where a JDK bug happened between one minor version and the next.

[lmm]

> Even if you do all developing on the latest LTS, you will want to be able to switch to whatever version is running on the dev or prod application servers to replicate a bug as closely as possible.

Occasionally, sure. But is it really frequent enough to worry about?

> By the way, you are ignoring the case I mentioned where a JDK bug happened between one minor version and the next.

I am, because I don't see why it's a case you'd worry about. Just install the version without the bug.

I mean sure, I can see some minor advantages to making it easy to change JDK versions. But for how often you want to do that, it really doesn't seem worth the overhead of having another moving part in your setup.

[Freak_NL]

Just install the version without the bug? Have you never developed software in a company?

Sometimes the JDK version you are targetting cannot be changed at that time, for a variety of reasons, most beyond your control.

Sometimes the JDK contains or triggers a bug you need to workaround and test in various minor versions.

Sometimes you need to switch to the exact minor version used in production.

Often you need to switch JDKs even within a single project, more often with several projects.

In the years that I've used SDKMan the number of times I invoked it to switch JDK versions in a terminal was more than once on hundreds of days (along with hundreds of days where whatever I set it to was fine for weeks on end). All painless, quick, and easy. Why wouldn't anyone involved in developing Java in a corporate setting make life easier on themselves? Those are not 'minor advantages', those are major time and mental overhead savers. It's a trivial tool to install and maintain too with almost no overhead for me to worry about. And if it breaks? Then the last version I configured will just keep working, and I can spend maybe half an hour to set up an alternative. That hasn't happened yet, so for a tool I've been using for a decade or so, that's pretty good.

[lmm]

I've hit JVM bugs in my professional career, sure. I just don't see the scenario where you'd need to be switching back and forth more than occasionally.

If you're running x.0.3 in production, you'd run x.0.3 locally. If there's a JVM bug that your application hits on x.0.3, either it's a showstopper in which case you'll find a way to upgrade/fix production quickly, or it's something you can tolerate, in which case you can tolerate it in local dev too. If you decide it's time to upgrade to x.0.4, you'd upgrade to x.0.4 locally, test a bit, then upgrade to x.0.4 in production. What's the scenario where you need to keep switching between x.0.3 and x.0.4 locally? You upgraded application Y to x.0.4, then discovered that application Z hits a showstopper bug and needs to stay on x.0.3? That's not a situation that you let fester for months, you either fix or work around the bug pretty quickly, or you decide that x.0.4 is too buggy and put everything back to x.0.3, and for that short period sure theoretically you would want to develop application Y under x.0.4 but the risk of developing it under x.0.3 is pretty damn small.

I get the argument that the cost is pretty low. It's just this is addressing something that really doesn't feel like a problem for me, and something that I don't think should be acceptable for it to be a problem. The JVM always used to be something you could upgrade almost fearlessly, and I think there was a lot of value in that.