Assuming one has installed a JDK in /opt/java/jdk1.8.0_144 then:

1. Install the alternative for javac

   $ sudo update-alternatives --install /usr/bin/javac javac /opt/java/jdk1.8.0_144/bin/javac 1
   

2. Check / update the alternatives config:

   $ sudo update-alternatives --config javac
   

If there is only a single alternative for javac you will get a message saying so, otherwise select the option for the new JDK.

To check everything is setup correctly then:

$ which javac
/usr/bin/javac

$ ls -l /usr/bin/javac
lrwxrwxrwx 1 root root 23 Sep  4 17:10 /usr/bin/javac -> /etc/alternatives/javac

$ ls -l /etc/alternatives/javac
lrwxrwxrwx 1 root root 32 Sep  4 17:10 /etc/alternatives/javac -> /opt/java/jdk1.8.0_144/bin/javac

And finally

$ javac -version
javac 1.8.0_144

Repeat for java, keytool, jar, etc as needed.

sudo update-alternatives --config java

Configures the default for the program "java". That's the Java VM.

sudo update-alternatives --config javac

Configures the default Java compiler.

You can also see that, because the first command lists a lot of "JRE" (Java Runtime Environment) folders and the Program is just called "java".

If I check which version is being used by issuing the command java -version or javac -version, I can see, that each command changes the program being used.

However, using update-java-alternatives with a JDK Version changes both programs for me. Using the first commands, you can use a Java VM and Java Compiler from different JDKs.

update-java-alternatives requires presence of a file with extension .jinfo in directory /usr/lib/jvm. The openjdk package is shipped with a .jinfo file, the jdk of Oracle (formerly Sun) is not. As alternative, you configure alternatives without update-java-alternatives:

For example, to add java from jvm-directory /usr/lib/jvm/jdk-12.0.1 (default directory of Debian package of Oracle) with priority 2082, use the following command:

sudo update-alternatives --install /usr/bin/java java /usr/lib/jvm/jdk-12.0.1/bin/java 2082

As for switching for different development environments:

Are you talking about starting the IDE itself with different Java versions or using different versions in the IDE for compilation and running your app?

• For 1.: You can specify which JVM to use in the eclipse.ini, as described here. I don't know how to do that for the Arduino IDE.

• For 2.: In Eclipse you can select the JRE/JDK to be used in Window -> Preferences -> Java -> Installed JREs. And under Java -> Compiler you could choose an older Java compliance if you wish.

EDIT: This DigitalOcean page also has a very nice explanation of everything related to Java on Ubuntu.

It only changes a symlink located (on most distro I guess) at /etc/alternatives/java. Absolutely NO change in the environment variable you set $JAVA_HOME is made.

First look at from where the command is found, you can do :

$which java
/usr/bin/java

The which command shows /usr/bin/java in my Debian distro. This file is a symlink which points to /etc/alternatives/java.

$ls -l /usr/bin | grep java
java -> /etc/alternatives/java

Then you follow the symlink :

$ls -l /etc/alternatives/java
/etc/alternatives/java -> /path/to/my/java/installation/1.x/bin/java

This shows that /etc/alternatives/java is another symlink. When you do an update-alternatives on java, you just change this symlink target to another one.

Then, why doesn't the executed version change when you do the update-alternatives command ? I guess it's because of the order the executables are found in $PATH. Since you added a directory to the PATH environment variable, there are now two possible java executables : one in /usr/bin and the other in /opt/jdk1.8.0_9, but only the first one found will be taken into account when you'll type java commands.

And because you set

PATH=$JAVA_HOME/bin:$PATH

The first one will be found in $JAVA_HOME/bin aka /opt/jdk1.8.0_91 . Because you made /opt/jdk1.8.0_9 appear before /usr/bin which is defined by default in the the PATH variable. You can check it by typing in a terminal

$echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/path/to/my/java/installation/1.x/bin

You can see that my java/bin dir is located after the others defined in the PATH.

To correct this, you just have to concatenate $JAVA_HOME/bin after $PATH, like this :

PATH=$PATH:$JAVA_HOME/bin

This way you will be able to choose the default java executable from alternatives and the java exe found in $JAVA_HOME/bin will be discarded. But to be consistent, in most cases you should choose the same java exe as in $JAVA_HOME/bin.

The asterisk identifies the default entry, i.e. the alternative which would be used in automatic mode:

update-alternatives --auto javac

This doesn't appear to be mentioned in the manpage, but see the source code: + indicates the current selection, * the "best" selection.

Does your version have --set?

--set name path
Set the program path as alternative for name. This is equivalent to --config but is non-interactive and thus scriptable.

The entry marked with * signifies the current selection. It is the default only in the sense as you do not have to enter anything in update-alternatives if you do not want to change it.

The system default is always auto, which means that the setting will change to always choose the alternative with the highest priority, determined by the package maintainers. The asterisk appearing in a manual line means that someone has changed the alternative. The system will not alter this choice, even when priorities are changing when updates are installed. So yes, manual mode always has preference over auto mode. Apparently, someone has (manually!) changed the setting for the java binary, but the current alternative is still the same as would be chosen by the system in auto mode, therefor the entry is appearing twice.

If you would prefer to let the system choose the "best" alternative for the java path automatically, select 0 here. Be aware that especially Java applications might be picky about the used implementation and version, so be careful what you change. Java applications that are available from the Debian or Ubuntu repositories, respectively, should always be able to run with the default JRE.