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 java-package
.
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 update-alternatives
’ --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 /usr/lib/jvm
(e.g. .java-1.8.0-openjdk-amd64.jinfo
). (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. update-java-alternatives
and 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
-handling, since PATH
can’t be set to dynamically use JAVA_HOME
to choose java
, 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 PATH
).
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.