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
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
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
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
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
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.