JEnv - Easily Manage Multiple Java Versions
What is the problem?
Sometimes you want to work with different versions of the same tool. Maybe you want to use the latest version of Java for your pet projects but you’re required to run a LTS version for another project on the same dev machine. While virtualising a whole development environment to keep your installations separate is an option, and I’ve seen that work well before, adding an extra layer of complexity for local development can be frustrating especially if you’re trying to debug something tricky.
RVM, NVM others…
This isn’t a new problem and some ecosystems / languages have very mature solutions for installing, managing and swapping between different major and minor versions. Specifically, Ruby Version Manager (RVM) and Node Version Manager (nvm) are great tools for enabling one to seamlessly swap between different versions of their respective language. Those particular two also allow for installation of a specific version of a language which is great!
JEnv
JEnv therefore is a Java environment manager, it allows you to have multiple Java versions installed and swap between them. JEnv also allows you to easily manage JAVA_HOME inside your shell, globally, per-directly or just for the life of that shell session.
Unlike RVM and NVM JEnv doesn’t handle the actual installation of Java for you but installing Java isn’t particularly daunting in 2021! Even I pulled it off without too much hassle! ;-)
Installation
On OSX JEnv is available via brew, brew install jenv. On Linux you can install it by cloning the source repo and adding it to your $PATH. JEnv is essentially a bunch of clever bash scripts which you need to add to your path.
# from the docs
git clone https://github.com/jenv/jenv.git ~/.jenv
# Shell: bash
echo 'export PATH="$HOME/.jenv/bin:$PATH"' >> ~/.bash_profile
echo 'eval "$(jenv init -)"' >> ~/.bash_profile
# Shell: zsh
echo 'export PATH="$HOME/.jenv/bin:$PATH"' >> ~/.zshrc
echo 'eval "$(jenv init -)"' >> ~/.zshrc
Configuration
After installation running jenv doctor will let us know if everything is okay.
~> jenv doctor
[OK] No JAVA_HOME set
[ERROR] Java binary in path is not in the jenv shims.
[ERROR] Please check your path, or try using /path/to/java/home is not a valid path to java installation.
PATH : Users/... long path here...
[OK] Jenv is correctly loaded
So we’ve got a working JEnv installation but we need to either install a version of Java or inform JEnv of any versions we currently have installed. For example if I install java 16 I can then add it to JEnv like so:
~> brew tap AdoptOpenJDK/openjdk
~> brew install --cask adoptopenjdk16
~> jenv add /Library/Java/JavaVirtualMachines/adoptopenjdk-16.jdk/Contents/Home/
openjdk64-16 added
16 added
# and now…
~> jenv doctor
[OK] No JAVA_HOME set
[OK] Java binaries in path are jenv shims
[OK] Jenv is correctly loaded
Usage
Using JEnv is really simple. You can list all the Java versions JEnv is aware of with jenv versions.
~> jenv versions
* system (set by /Users/vagrant/.jenv/version)
11
11.0
11.0.10
16
openjdk64-11.0.10
openjdk64-16
As you can see, the system wide version of Java can be set in a file ~/.jenv/version. There is also a utility command provided by JEnv jenv global <version> which will set the system version.
For a specific project you can add a .java-version file into the root directory of a project and JEnv will automatically select the version for you. There is another utility command jenv local <version> which will create the .java-version file for you.
~> echo 11 > .java-version
~> jenv version
11 (set by /Users/vagrant/tmp/.java-version)
~> jenv local 16
~> cat .java-version
16
~> jenv version
16 (set by /Users/vagrant/tmp/.java-version)
And that is pretty much it. I’d recommend looking at the docs for more info if you’re keen. JEnv will allow you to specify and easily swap between different versions of Java. Using the .java-version file can help ensure everyone in a team is running the same version of Java without needing to manually swap every time one changes project.
JEnv can also be used in a CD / build agent which, again, can help a lot by setting the correct Java version when building a project automatically using the same dot file mechanism. All in all I find it a very useful and simple tool.
Thanks for reading! :)