When I say that I recommend
update-java-alternatives for Java alternatives, I’m assuming that whatever Java providers are installed provide the necessary infrastructure. That’s the case for the OpenJDK packages available in Debian and its derivatives, but not necessarily for other JDK packages, and it’s unlikely to be the case for a manually-installed JDK. Oracle JDK packages created using
java-package do provide the necessary infrastructure. I don’t think it’s a sensible use of people’s time to set up the alternatives for all the Java commands manually: if you want to install the Oracle JRE or JDK, use
The point of
update-java-alternatives is to allow a consistent setup of the default JRE/JDK tools. In theory, this could be done using
--slave relationships; however that doesn’t work generally for OpenJDK packages because you can have a subset of the available tools installed, which
update-alternatives doesn’t deal with. Hence the creation of
update-java-alternatives, which takes care of whatever tools are installed and doesn’t complain about anything else. For
update-java-alternatives to work though, JRE/JDK packages have to provide the necessary information, in a file in
update-alternatives on RPM-based distributions does cope with this, apparently, but I haven’t looked into the details.)
Java itself has its own way of choosing among multiple installed JREs/JDKs, the
JAVA_HOME environment variable.
JAVA_HOME are really complementary: it should be possible to set both to point at different JREs/JDKs, depending on your requirements.
update-java-alternatives allows the system administrator to specify which JRE/JDK should be the default on a system (in fact, one might consider that it allows the package maintainers to specify which should be the default — it’s all supposed to work transparently for the administrators and users).
JAVA_HOME allows any user or startup script to specify which JRE/JDK should be used in a specific environment. Where things fall apart somewhat on Unix-style systems is with
PATH can’t be set to dynamically use
JAVA_HOME to choose
javac etc. (unlike on Windows); so you need to remember to re-set your
PATH when you change your
JAVA_HOME, if you want your default
java etc. to track your
JAVA_HOME setting (add
$JAVA_HOME/bin to the start of your
The take-away from all this is similar to my answer to Can setting up environment variables replace using `update-alternatives`?: the system administrator should use
update-java-alternatives to define the default JRE/JDK for the system (or let the packages choose themselves), and users can use
JAVA_HOME to define the JRE/JDK for a specific environment.