Comment by jakebasile
13 hours ago
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.
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?
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
direnv is great for switching any envnvariables let given directory.
I use it when I have projects with different jdks or nodejs.