- Most of the JDKs mentioned are simply builds of openjdk. There are a few exceptions with alternative runtimes from e.g. IBM. But unless you have a good reaon to use those, use any OpenJDK build. They are functionally identical and the certified ones pass an extensive test suite to guarantee that. Coretto is a safe bet with long term support and backported fixes.
- There's a difference between developers and production usage here. Tools like sdk man are for developers that need to switch between specific versions in different projects. You see the same in the python, ruby, js, etc. world. System wide installations aren't that useful. Unlike many of those, project dependencies are never system wide. There's no global installation of Java dependencies.
- Avoid Oracle's builds unless you need them for compliance reasons. Their licensing can get expensive and they are famously pretty aggressive on enforcing terms. There is no functional advantage to using their builds. They aren't faster or better in any way. There is no Oracle specific secret sauce.
- If you are on Linux or mac, getting your sdk via your favorite package manager is fine for casual use. Just be aware that this might not necessarily work with all software projects you want to work on. If that matters to you, that's what sdkman is for.
- JDKs take up a lot of space. A lot of tools are trigger happy to add JDKs but don't necessarily remove them. Tracking down and removing redundant JDKs is something I have to do regularly. Some tools try to be a bit too smart and will ignore the presence of perfectly good jdks I have installed with sdkman (e.g. intellij).
- Use containers for deployment and pick the right base image. You should not need server side jdk installations unless you are doing things the old school way.
And don’t hesitate to use a JRE (Java Runtime Environment) if all you need is to run java/jvm applications - assuming the application doesn’t already ship with its own runtime. A JDK is roughly 140 MB, while a JRE is about 60 MB (and can be further minimized). I’ve seen installations of the full OpenJDK just to run apps, which is unnecessary in most cases.
I just don't see the point in installing a version manager specifically for the JDK. It's fine to have multiple installed, and at least on Debian-likes you have the built in update-java-alternatives method to switch between them.
On macOS I wrote my own 9-line Zsh function that lists the JDKs available and sets JAVA_HOME.
In containers you'll never switch at all, just install whatever you want and be done with it.
ETA: I see in another comment someone said this doesn't work for things that aren't OpenJDK. But I've yet to run into a situation where I'd want to install anything except OpenJDK. That said, I think update-java-alternatives would work with them if they provide deb files to install themselves.
The update-java-alternatives tool is suitable for adjusting the JDK for everything at once, but it lacks the ease of use of something like SDKMan when you have one project stuck at Java 8 and another on 11, and another on 17, or perhaps you're testing a branch on 24, etc.
Then it's just:
sdk use java 11.0.29-tem
And in that terminal it will use that, while another terminal happily uses a different version. That's useful when you are running two tools on different Java versions which interact. Installing another version is trivial too.
pro tip: don't bother with SDKMAN. use https://mise.jdx.dev to install Java, it can also install a bunch of other languages and tools. it's most likely the last tool version manager you'll ever need.
I found the documentation confusing and as so often with general-approach tools too overwhelming for what I'm trying to do. sdkman works fine for what I need it for and usually you only need one instance of gradle and maven installed.
And sdkman is written in rust and only needs curl, zip and unzip, no JVM.
With Mill build tool that I'm working on, you don't need to install Java at all! (https://mill-build.org/blog/16-zero-setup.html). Instead, it gets bootstrapped automatically when you launch the `./mill` script like any other third-party dependency. You can use any version you want just by editing the config file and it'll be downloaded and cached on demand. You can also configure different JVM versions to use in different Java modules without worrying about conflicts between them.
You don't need to globally install Apache-Commons, nor is there a "Apache Commons Version Manager" that you need to first install to then manage your different versions of Apache Commons. So why should the JVM need such a thing? Well with Mill, it doesn't
I use version managers for Python, Node, Ruby, and others. But for Java, none. I have all the recent versions of Java on my Linux and Windows devices. I download the zip and extract it to a common directory "Java". Setting the path within IDEs is easy, and is mostly unavoidable (regardless of a version manager). Running standalone programs is not that complicated too.
Yes, I have a dead-simple env.bat/env.sh file that sets up specific Java and Maven versions for programs that IDEs struggle with building. I don't see the need to set up an extra tool to install more Java versions, because I don't rebuild my dev environments from scratch every week. My Java 8 installation is three-years old now and has survived a complete Windows reinstallation.
+1 sdkman! is awesome. I've been using sdkman! for a decade to manage Java installations. Doesn't seem to work on freebsd though, which I have to use freebsd's pkg instead.
On Windows, the only sane way to install Java seems to be scoop.sh or chocolatey
JDKs are just a directory tree. Not sure what you mean on Windows, you simply unpack the JDKs to whatever directories you want, and set PATH and/or JAVA_HOME according to which you want to use, and/or switch them in your IDE.
The advantage of using a package manager like scoop or chocolatey is that you have a unified interface to manage multiple versions of JDK, and you can switch the default version system-wide on the fly, regardless of your IDE:
You can do that manually but it's tedious if you want to use multiple JDKs. Assuming you want to test two apps outside of an IDE, one only supports Java 8 API, and the other supports Java 21 API, you don't want to edit JAVA_HOME every time you switch back and forth between the two apps.
With scoop you can just launch the terminal and run `scoop reset [java-version]`
Fortunately, the Java ecosystem isn’t JS where breakage is so common that you have to be extra careful about the version of Node you’re using. As a Clojure programmer, I have never seen a case where it mattered which vendor my JVM was coming from, and 95% of the time I don’t care which version I’m using, as long as it’s reasonably recent.
For the remaining 5%, on macOS, my JVM version manager is this zsh one-liner:
> I have never seen a case where it mattered which vendor my JVM was coming from
As I understand it, Oracle's JVMs only get free updates for a limited time. If you keep using them after that you risk getting caught in a license audit.
Before even deciding which Java to install, you have to decide which _version managers_ to use:
1. No version manager, download and install manually. Not that hard, since it's just a zip file and maybe set JAVA_HOME envvar. If you need multiple versions to co-exist, skip this.
2. Use OS' "native" package manager. Brew, apt, chocolatey.
3. Generic package manager like asdf.
4. SDKMAN!, JBang, jEnv, jabba...
Deciding is easy. But remembering which one you used 6 months ago when you want to install another version...
I'd skip that and use mise. It's an asdf compatible manager and does so much more. It manages scripts (replacing make), environment variables and it's super fast.
> multiple vendors has always been a thing in Java since the early 2000's.
Early 2000s? There was usually one language version that circulated. We had the blackdown java on debian, whatever version sun hosted (1.3?) and something IBM made which was probably on a password protected ftp site available to corporate clients. And it was like that for years. Now there's like 10 vendors supporting 3-5 different major language versions that change every few months.
It's really handy for switching between projects that are on different Java versions, plus tools like IntelliJ pick up on the correct version via the SDKMAN! configuration as well.
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.
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
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.
> 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.
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.
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.
> 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.
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.
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.
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.
Picking a JDK is simple. You pick the latest Temurin LTS. It'll work, and if it doesn't, grab the Zulu with JavaFX already plugged in or suss out the incantation for implanting it into your Temurin through web search.
Besides JDK management SDKMan also provides an easy to understand interface for toolchains for things like Clojure and Kotlin and also stuff such as Quarkus.
Coming from Python, I get the feeling Java tooling is ripe for an astral-shaped astroid.
Am I just a Java rookie, or would Java benefit from equivalents for Python's ruff/uv/ty?
Obviously, lots of tooling already exists (Python's did too). But distilling all the lore and xml into a handful of fast opinionated cli tools seems useful to me anyway.
I remember manually choosing dependencies by pasting them from maven to pom.xml and jetbrains IDE kindly nudged me every day to keep up to date whenever newer versions were available. Version massaging took a large portion of the day because I was too autistic to ignore a yellow alert.
There's nothing like direnv + nix + a flake with the appropriate dev shell config...
And seriously, any LLM can write the .envrc, nix.conf, flake.nix files if it's too complicated.
Couple of points here:
- Most of the JDKs mentioned are simply builds of openjdk. There are a few exceptions with alternative runtimes from e.g. IBM. But unless you have a good reaon to use those, use any OpenJDK build. They are functionally identical and the certified ones pass an extensive test suite to guarantee that. Coretto is a safe bet with long term support and backported fixes.
- There's a difference between developers and production usage here. Tools like sdk man are for developers that need to switch between specific versions in different projects. You see the same in the python, ruby, js, etc. world. System wide installations aren't that useful. Unlike many of those, project dependencies are never system wide. There's no global installation of Java dependencies.
- Avoid Oracle's builds unless you need them for compliance reasons. Their licensing can get expensive and they are famously pretty aggressive on enforcing terms. There is no functional advantage to using their builds. They aren't faster or better in any way. There is no Oracle specific secret sauce.
- If you are on Linux or mac, getting your sdk via your favorite package manager is fine for casual use. Just be aware that this might not necessarily work with all software projects you want to work on. If that matters to you, that's what sdkman is for.
- JDKs take up a lot of space. A lot of tools are trigger happy to add JDKs but don't necessarily remove them. Tracking down and removing redundant JDKs is something I have to do regularly. Some tools try to be a bit too smart and will ignore the presence of perfectly good jdks I have installed with sdkman (e.g. intellij).
- Use containers for deployment and pick the right base image. You should not need server side jdk installations unless you are doing things the old school way.
And don’t hesitate to use a JRE (Java Runtime Environment) if all you need is to run java/jvm applications - assuming the application doesn’t already ship with its own runtime. A JDK is roughly 140 MB, while a JRE is about 60 MB (and can be further minimized). I’ve seen installations of the full OpenJDK just to run apps, which is unnecessary in most cases.
I just don't see the point in installing a version manager specifically for the JDK. It's fine to have multiple installed, and at least on Debian-likes you have the built in update-java-alternatives method to switch between them.
On macOS I wrote my own 9-line Zsh function that lists the JDKs available and sets JAVA_HOME.
In containers you'll never switch at all, just install whatever you want and be done with it.
ETA: I see in another comment someone said this doesn't work for things that aren't OpenJDK. But I've yet to run into a situation where I'd want to install anything except OpenJDK. That said, I think update-java-alternatives would work with them if they provide deb files to install themselves.
The update-java-alternatives tool is suitable for adjusting the JDK for everything at once, but it lacks the ease of use of something like SDKMan when you have one project stuck at Java 8 and another on 11, and another on 17, or perhaps you're testing a branch on 24, etc.
Then it's just:
And in that terminal it will use that, while another terminal happily uses a different version. That's useful when you are running two tools on different Java versions which interact. Installing another version is trivial too.You can also check in an .sdkmanrc into each respective project which defines the required Java version.
Then SDKMAN! will perform the switch automatically when you enter the directory.
https://sdkman.io/usage/#env-command
What does it do, other than presumably switching PATH and JAVA_HOME? The documentation on the website doesn’t really say.
Does it have any interaction with e.g. Maven Toolchain?
direnv is great for switching any envnvariables let given directory.
I use it when I have projects with different jdks or nodejs.
pro tip: don't bother with SDKMAN. use https://mise.jdx.dev to install Java, it can also install a bunch of other languages and tools. it's most likely the last tool version manager you'll ever need.
I found the documentation confusing and as so often with general-approach tools too overwhelming for what I'm trying to do. sdkman works fine for what I need it for and usually you only need one instance of gradle and maven installed.
And sdkman is written in rust and only needs curl, zip and unzip, no JVM.
Ah, it was written in Groovy last time I looked at it I believe. In any case here’s how to install a default java:
`mise ls-remote java` to show all vendors and versions, or just `mise latest java@temurin` (or any other vendor) to get the latest version string
`mise use -g java@<version>` to install it and set it as a default
I'll vouch for that - mise is awesome and replaces both sdkman, pyenv, and other similar tools that are restricted to one ecosystem.
With Mill build tool that I'm working on, you don't need to install Java at all! (https://mill-build.org/blog/16-zero-setup.html). Instead, it gets bootstrapped automatically when you launch the `./mill` script like any other third-party dependency. You can use any version you want just by editing the config file and it'll be downloaded and cached on demand. You can also configure different JVM versions to use in different Java modules without worrying about conflicts between them.
You don't need to globally install Apache-Commons, nor is there a "Apache Commons Version Manager" that you need to first install to then manage your different versions of Apache Commons. So why should the JVM need such a thing? Well with Mill, it doesn't
I use version managers for Python, Node, Ruby, and others. But for Java, none. I have all the recent versions of Java on my Linux and Windows devices. I download the zip and extract it to a common directory "Java". Setting the path within IDEs is easy, and is mostly unavoidable (regardless of a version manager). Running standalone programs is not that complicated too.
Yes, I have a dead-simple env.bat/env.sh file that sets up specific Java and Maven versions for programs that IDEs struggle with building. I don't see the need to set up an extra tool to install more Java versions, because I don't rebuild my dev environments from scratch every week. My Java 8 installation is three-years old now and has survived a complete Windows reinstallation.
Good luck when you sysadmin apply a decent automated security suite and removes the old Java 8 installation because isn't updated
If sysadmins do that then you have bigger problems than just disappearing jdks. Run.
+1 sdkman! is awesome. I've been using sdkman! for a decade to manage Java installations. Doesn't seem to work on freebsd though, which I have to use freebsd's pkg instead.
On Windows, the only sane way to install Java seems to be scoop.sh or chocolatey
JDKs are just a directory tree. Not sure what you mean on Windows, you simply unpack the JDKs to whatever directories you want, and set PATH and/or JAVA_HOME according to which you want to use, and/or switch them in your IDE.
The advantage of using a package manager like scoop or chocolatey is that you have a unified interface to manage multiple versions of JDK, and you can switch the default version system-wide on the fly, regardless of your IDE:
I also wrote a short guide on my website: https://raizensoft.com/tutorial/install-java-gamedev/Thanks, but what does “the default version system-wide” mean, other than setting environment variables or replacing the JDK in a fixed location?
You can do that manually but it's tedious if you want to use multiple JDKs. Assuming you want to test two apps outside of an IDE, one only supports Java 8 API, and the other supports Java 21 API, you don't want to edit JAVA_HOME every time you switch back and forth between the two apps.
With scoop you can just launch the terminal and run `scoop reset [java-version]`
Fortunately, the Java ecosystem isn’t JS where breakage is so common that you have to be extra careful about the version of Node you’re using. As a Clojure programmer, I have never seen a case where it mattered which vendor my JVM was coming from, and 95% of the time I don’t care which version I’m using, as long as it’s reasonably recent.
For the remaining 5%, on macOS, my JVM version manager is this zsh one-liner:
> I have never seen a case where it mattered which vendor my JVM was coming from
As I understand it, Oracle's JVMs only get free updates for a limited time. If you keep using them after that you risk getting caught in a license audit.
It’s okay to use them for development and testing, just not in production. But yes, you don’t get LTS updates.
Before even deciding which Java to install, you have to decide which _version managers_ to use:
1. No version manager, download and install manually. Not that hard, since it's just a zip file and maybe set JAVA_HOME envvar. If you need multiple versions to co-exist, skip this.
2. Use OS' "native" package manager. Brew, apt, chocolatey.
3. Generic package manager like asdf.
4. SDKMAN!, JBang, jEnv, jabba...
Deciding is easy. But remembering which one you used 6 months ago when you want to install another version...
I'd skip that and use mise. It's an asdf compatible manager and does so much more. It manages scripts (replacing make), environment variables and it's super fast.
I have a feeling somebody will link that xkcd post soon...
Perhaps. But I wouldn't be so sure. It has functionality to replace the following tools:
- make (via its tasks feature)
- direnv (via its environments features)
- Just about most package managers (via it's dev tools features)
It has backends for just about anything (aqua, cargo, asdf, gem, github, go, etc).
It allows for locking your tooling similar to a package.json lock file.
And the nice thing is that it does it a lot better those tools (I recently found out make gobbles up any error codes and returns 2).
I don't get the point.
First of all, multiple vendors has always been a thing in Java since the early 2000's.
Second, configuring a couple of environment variables isn't that much of a challenge.
Third, all IDEs have an option to use a bundled JVM, and allow for JVM selection per project.
Finally, for applications the modern way is to build the runtime alongside the application, or AOT compilation.
> multiple vendors has always been a thing in Java since the early 2000's.
Early 2000s? There was usually one language version that circulated. We had the blackdown java on debian, whatever version sun hosted (1.3?) and something IBM made which was probably on a password protected ftp site available to corporate clients. And it was like that for years. Now there's like 10 vendors supporting 3-5 different major language versions that change every few months.
Yes, doesn't matter if it was commercial or not, or what operating systems.
We are not talking about what was available only to GNU/Linux folks as free beer.
If you're going to pick some words and gloss over the rest, just don't respond.
If you are going to ignore Java's market adoption history since its introduction in 1996, just don't bother.
Umm yeah I won't ignore it. Enjoy whatever you think you've accomplished by saying that.
Happy sdkman user for many years.
Never understood why you’d use sdkman for Java. I just do:
1. brew install openjdk@<version>
2. ln -s <homebrew path> </Library/JavaVirtualMachines/>
3. /libexec/java_home -v <version>
Afaik, with some aliases in you *shrc it basically reimplements sdkman, what else does it give you?
This works if all you need is OpenJDK. Per the article, sdkman allows one to install and switch between different versions and brands of JDKs.
> Per the article, sdkman allows one to install and switch between different versions and brands of JDKs.
OK but what benefit does that give? I hope we're not back to the bad old days of different apps needing different brands of JDK to run on.
It's really handy for switching between projects that are on different Java versions, plus tools like IntelliJ pick up on the correct version via the SDKMAN! configuration as well.
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.
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
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.
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.
> 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.
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.
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.
> 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.
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.
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.
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.
Steps 2 & 3 expands to any installation method and version of java
From what I’ve seen is most organisations have moved to Amazon Corretto, and stuck with it.
It’s TCK-certified, supported by Amazon, and completely free.
So I don’t see the need to use any other distribution, unless it is for a niche requirement.
Ever since I found `asdf`, I threw away jenv, nvm, fmn and rvm.
Same here, having a different version manager per language ecosystem got tiring due to the small differences.
I used asdf for a while but moved to mise-en-place (mise). Same reasons though, one tool manager for all the tools.
That's a lot of words to promote SDKMan.
Picking a JDK is simple. You pick the latest Temurin LTS. It'll work, and if it doesn't, grab the Zulu with JavaFX already plugged in or suss out the incantation for implanting it into your Temurin through web search.
Besides JDK management SDKMan also provides an easy to understand interface for toolchains for things like Clojure and Kotlin and also stuff such as Quarkus.
Coming from Python, I get the feeling Java tooling is ripe for an astral-shaped astroid.
Am I just a Java rookie, or would Java benefit from equivalents for Python's ruff/uv/ty?
Obviously, lots of tooling already exists (Python's did too). But distilling all the lore and xml into a handful of fast opinionated cli tools seems useful to me anyway.
I remember manually choosing dependencies by pasting them from maven to pom.xml and jetbrains IDE kindly nudged me every day to keep up to date whenever newer versions were available. Version massaging took a large portion of the day because I was too autistic to ignore a yellow alert.
I would say as well as using SDKMan, you should use Jenv shell plugin to easily manage your JDK versions across projects.
https://github.com/jenv/jenv
All you have to do is link your SDKMan binaries with Jenv and you can easily switch with one command.
There's nothing like direnv + nix + a flake with the appropriate dev shell config... And seriously, any LLM can write the .envrc, nix.conf, flake.nix files if it's too complicated.
Or just `apt install default-jdk-headless` and move on with your life
There's always Gradle Toolchains as well, which allows you to put the JDK configuration in the branch next to the source code.
The version manager approach feels like a giant step backward to me. Manage dependencies with containers.
[dead]