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.
Installing Java in 2025, and Version Managers
21–30 of 65 posts
Re: Installing Java in 2025, and Version Managers
#22From 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.
Re: Installing Java in 2025, and Version Managers
#23I 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.
Re: Installing Java in 2025, and Version Managers
#24Earlier quoted context omitted.
Never understood why you’d use sdkman for Java. I just do: 1. brew install openjdk@ 2. ln -s 3. /libexec/java_home -v 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.
Steps 2 & 3 expands to any installation method and version of java
Re: Installing Java in 2025, and Version Managers
#25Earlier quoted context omitted.
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
Re: Installing Java in 2025, and Version Managers
#26Fortunately, 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:
jvm () { export JAVA_HOME=`/usr/libexec/java_home -v $1`; }Re: Installing Java in 2025, and Version Managers
#27Ever since I found `asdf`, I threw away jenv, nvm, fmn and rvm.
Re: Installing Java in 2025, and Version Managers
#28I 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
Re: Installing Java in 2025, and Version Managers
#29I 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. ET…
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
Re: Installing Java in 2025, and Version Managers
#30Earlier quoted context omitted.
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
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.