[lmm]

OK but again what's the use case for that? Can you not just use a new version of Java for all your projects, at most setting -source/-target in your project configuration? Certainly in the old days it was always backwards compatible, at least enough that you could develop under a current version and maybe just have a CI job to check that your code still worked on old versions.

[vladgur]

In a large organization with hundreds of business-critical Java applications you can bring them all up to one version at once. It’s quite normal to have multiple versions of JDK being used by different applications

[Freak_NL]

It's not only normal, it is completely to be expected. Even if you have only one project, there will come a time when one branch will be used to test the jump from 17 to 24 or something like that, so you'll work on that, but also switch back to the master branch when a colleague needs some help there.

  sdk use java xxx

And done. A new LTS is released? Just sdk install it. Set the one you use most as default, and focus on the project instead of managing JDKs.

Oh, and very occasionally you'll actually get hit by a bug within one Java major version (like when they removed historic offsets from the timezone database included in the JVM, that was fun). At that point being able to switch between minor versions easily is quite nice.

[lmm]

> there will come a time when one branch will be used to test the jump from 17 to 24 or something like that, so you'll work on that, but also switch back to the master branch when a colleague needs some help there.

But can you not just install 24 on your dev box and use that to work on either branch, maybe with -source/-target arguments? It never used to be a problem to develop with a newer JVM even if it was an older project.

[yardstick]

Note: Java compiler versions from 9 onwards have lost the ability to -target 1.5 and earlier.

Sometimes you still need Java 8 to compile for super old programs — think decades old IoT devices too small to handle newer JVMs that you still need to do the occasional minor update for.

But really sdkman is just nice to be able to quickly install and quickly switch jvms without worrying about any opinions the os package manager may have. If I want an old jre8, do I need to fuss around with finding the right package repo for my arch etc, or should I just use sdkman and be done with it.

[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 been lucky enough that the large organisations I worked for generally had policies and enforcement to ensure that all applications were kept current. It's more initial effort but it pays dividends.

But even if you don't have that, most people work on at most a handful of apps at a time, and again I would defer checking against a specific version to CI most of the time rather than switching around which JVM I'm using locally, unless your code was very tightly coupled to JVM internals somehow.