— java, sdkman, archlinux, vscode-java — 2 min read
For java development it is sometimes necessary to switch between different jdk versions. That is my SDKMAN setup on arch linux to deal with it.
There is one AUR package available called sdkman but its seems to be an unofficial sdkman client.
To use the official one you should follow the instructions from here. It is pretty fast and easy.
Basically you install it via curl from the command line.
This command installs all necessary scripts and files you need in your home directory.
And to have a proper initialized sdkman for each shell session you have to add one line to you .bashrc or .zshrc.
Of course you need to replace the home directory name accordingly to your username or you might use something like $HOME from your env here.
To avoid collision with java installed on system level it is useful to unset the default system java environment by using the archlinux-java
script that comes along with the java-runtime-common package.
So far so good. We are ready to use sdkman. To install a java version we check which of them are available.
To install one of the candidates we are using the identifier from the last column of the output table.
Whenever you want to switch from one version to another you either use the use or default command.
The different between those is that use only changes the version for the current shell and default will change it for every shell.
As long as you only working from the in your shell everything is working fine. But in case you want to work with an IDE like vscode-java and you are not starting it from the command line the current configured java version is not picked up properly. Why not and how does it work? There are several ways for vscode-java to define the jdk path that should be used.
java.home setting in VS Code settings (workspace then user settings)JDK_HOME environment variableJAVA_HOME environment variableThese are the steps and the order of how it tries to find the correct jdk path. Lets go through them.
First option to use java.home would be easy, but it only fixes the problem for vscode-java and other applications would still have issues.
Last option wont work since sdkman and candidates are installed in our users directory and not on system level.
Second and third option seems to be the way to go.
I chose JAVA_HOME because it seems to be more the standard of what is used by the majority of applications.
Indeed, sdkman already exports the proper JAVA_HOME environment variable, but only on shell scope.
We need it globally so that it is also picked up by application that are spawned by our window manager.
Normally you would define global environment variable somewhere in /etc/environment or /etc/profile.
But since sdkman runs on our user level it is a bad idea to put something user specific at system level and other users would get into trouble.
What we want is to define it global but only for our user.
One way to do it, is to use the systemd daemon and put or environment variable to a conf file into our ~/.config/environment.d/ directory.
After a reboot or a re-login of your user JAVA_HOME should get picked up by vscode-java and other applications.
Because the value here points to a symlink it will also work whenever you switch java versions.
For those who are enjoying completions for zsh, they are also available for SDKMAN. Follow the instructions from here to set them up.
Happy version switching!