Up until September 2017 when Java 9 was announced, new JDK versions rarely came out and on a irregular schedule. Nowadays, we see a new version every 6 months. This has more than surely spiced things up in the Java ecosystem. In order words we have seen more releases in the last 3 years than in the whole previous 20 something years.

As developers we are always eager to experiment the new features that come out, however it is also our duty to make sure we deliver things on time and that they also run in production. This often means compromising our appetite for research in exchange for stability. While most releases did not introduce any braking changes, some, like JDK9 which converted some legacy sun.* packages into private classes involved some tool rework in order to take this into account. This meant that you couldn’t get the latest JDK on your machine where you kept production code.

An issue emerged. New versions need managing in order to coexist. No single problem has a single solution.

1. Manually managing version - the simplest way to get around this is to manually install the desired versions onto your machine and then simply changing it as part of a script. In UNIX like systems you would normally edit your ~/.bash_profile script and add a like something like export JAVA_HOME=/path/to/jdk/location/bin and then you would either source that file or open a new terminal. For Windows systems, you would have to presumably change the environment variable by hand. Searching the web you might find various flavours of this approach.

2. Using OS-dependant tools - as the number of versions increased purpose-built tools started being created. Referring back to the operating systems I have mostly used for developing, I have come across these options. MacOS leverages its package manager homebrew and proposes to use homebrew-cask to install the versions of java of your desire and then switch between versions using jenv. For Linux my preferred option was to use update-alternatives. This provided pretty much the same functionality as jenv however installing the necessary versions was still a manual task.

3. Using SDKman - I was incredibly happy to stumble upon SDKman. In my humble opinion it is the best alternative for managing multiple JDK versions. It runs both on MacOS and Linux - there is also a way to making it work on Windows through WSL - Windows Subsystem for Linux. Installing it is pretty straight forward, curl -s "https://get.sdkman.io" | bash and you’re ready to go. Next thing you need to do is simply run sdk list java find the version you are looking for and then run sdk install java [identifier]. Once installed, in order to switch between versions simply run sdk default java [identifier] and you are done. Make sure to check the version has been updated using java -version. One thing I particularly enjoyed is the fact that the JDK are installed in our home directory which makes it easy to add them in your favourite IDE.

In addition to managing JDK versions SDKman can also help you manage additional languages, either JVM based - Groovy, Scala or tools such as Maven, Gradle, SBT and so on. All in all I think it is a cool tool that greatly simplifies working with multiple versions in the Java ecosystem.