1

When installing the latest Oracle JDK (8 or 9) on Ubuntu 16.04, I found several discussions:

I summarize their ways into the following:

  • Some use update-alternatives. Among them, some use it for java, javac and javaws (example), while some use it for more commands ( example, example, example, example). I am not sure which one gives the complete list of commands to apply update-alternatives to.

  • Some use update-java-alternatives (example, example, ), but some says it doesn't work for manual installation.

  • Some use both update-alternatives and update-java-alternatives (example)

  • Some change several environment variables, and think that the previous two approaches are complicated unnecessarily (example, )

  • Some both use update-alternatives and change several environment variables: (example)

  • Some install from ppa:webupd8team/java (example, example, example)

I wonder which way(s) is recommended?

Thanks.

Tim
  • 101,790

1 Answers1

5

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.

Stephen Kitt
  • 434,908