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.

This is the correct approach to hand-inserting an alternative in the alternatives system.

Your alternatives tool is a port of the original Debian update-alternatives tool. With that tool, and your port, there is

update-alternatives --display jre_1.8.0_openjdk

which should tell you the "generic name" to use with --install. The vanilla Debian tool also has

update-alternatives --query jre_1.8.0_openjdk

However: On RHEL, Java installations are installed with the --slave option to --install so that the JRE is switched in lockstep with the java program. In fact, there are between 20 and 50 --slave options that the install scripts for the packages set up. Witness the likes of this post-install script template for OpenJDK from AdoptOpenJDK (which isn't even setting up a JRE alternative, notice) for example.

Really this isn't something that you are going to be able to construct, error-free, longhand, to match what you already have. Don't download and install from raw TAR archives. Use the packages.

Assuming you installed the OpenJDK6 with:

sudo apt-get install openjdk-6-jdk

In Ubuntu 64 bit, make sure the paths are valid for your installation (change if using 32bit version):

/usr/lib/jvm/java-6-openjdk-amd64/jre/bin/java

/usr/lib/jvm/java-6-openjdk-amd64/bin/javac

Setup update-alternatives:

sudo update-alternatives --install "/usr/bin/java" "java" "/usr/lib/jvm/java-6-openjdk-amd64/jre/bin/java" 1
sudo update-alternatives --install "/usr/bin/javac" "javac" "/usr/lib/jvm/java-6-openjdk-amd64/bin/javac" 1

sudo update-alternatives --set java /usr/lib/jvm/java-6-openjdk-amd64/jre/bin/java
sudo update-alternatives --set javac /usr/lib/jvm/java-6-openjdk-amd64/bin/javac

Alternatively, make sure the correct version is checked for both Java and compiler:

sudo update-alternatives --config java
sudo update-alternatives --config javac

List the installed Java alternatives with:

sudo update-alternatives --list java
sudo update-alternatives --list javac

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.

On Ubuntu (and other Debian based distributions) /usr/bin/java is just a symlink to /etc/alternatives/java, which is itself a symlink to /usr/lib/jvm/$SOMEVERSION/bin/java.

This way you can choose your preferred java version just by changing this one link.

As you removed /etc/alternatives/java you can just create a new link using:

 ln -s /usr/lib/jvm/jdk1.7.0_45/jre/bin/java /etc/alternatives/java

Alternatively you should be able to use the alternatives-system:

 update-alternatives --set java /usr/lib/jvm/jdk1.7.0_45/jre/bin/java

Alternatives

Alternatives is a tool that will manage the locations of the installed software using links under the control of the alternatives tool.

These links are ultimately managed under /etc/alternatives with intermediate links created under a directory in $PATH, typically /usr/bin.

Example

$ ls -l /usr/bin/java
lrwxrwxrwx. 1 root root 22 Feb 24 17:36 /usr/bin/java -> /etc/alternatives/java

$ ls -l /etc/alternatives/java
lrwxrwxrwx. 1 root root 73 Feb 24 17:36 /etc/alternatives/java -> /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.5.0.fc19.x86_64/jre/bin/java

$JAVA_HOME

$JAVA_HOME is where software can be told to look through the use of an environment variable. Adding it to the $PATH simply adds the executables present in $JAVA_HOME/bin to your $PATH. This is sometimes necessary for certain applications.

The 2 mechanisms are related but can be used together or independent of each other, it really depends on the Java application which mechanism is preferable.

What I do

I typically use $JAVA_HOME for some GUI applications, but in general use it only for server installations that make use of Jetty, Tomcat, or JBOSS, for example.

For these installations I'll still use alternatives to manage the Java installations prior to setting the $JAVA_HOME. I like doing it this way in cases where I might need to have multiple installations of Java.

Alternatives does allow you to have certain tools use one installation of Java while other tools use a completely different one.

References

• 5 Minute Guide to using the alternatives Command on Fedora/CentOS/RHEL
• Using 'Alternatives' in Linux to use a different Java package

Thast's because you have altered IFS variable to use ':'

so when its output your variable its replaced with default output field separator which is 'space' thinking that ':' is input field separator .

you have take backup of it before using IFS like below :

OIFS=$IFS
IFS=':';

after 'for' loop is done , restore it :

IFS=$OIFS

Also remove the ':' which starts with no path preceding that

PATH=${PATH#:*}    

Your script should be like :

#!/bin/bash

export JAVA_HOME=$(dirname $(dirname `readlink -f /etc/alternatives/java`))

OIFS=$IFS
IFS=':';
for i in $PATH;
do
        JAVA1=$i/bin/java
        JAVA2=$i/java
        if [ -d "$i" ];
        then
                if [ ! -L "$JAVA1" ] && [ -x "$JAVA1" ] || [ ! -L "$JAVA2" ] && [ -x "$JAVA2" ];
                then
                        echo "dropping path: $i";
                else
                        NEW=$NEW:$i
                fi
        fi
done
IFS=$OIFS
PATH=$NEW:$JAVA_HOME/bin
PATH=${PATH#:*}
echo 
echo "Final:"
echo $PATH

To answer my own question, based on help from #centos on irc.freenode.net, to select/set on the command line:

# alternatives --set java java-1.8.0-openjdk.x86_64

For Ansible, looking at the source of the alternatives module it requires a path to the java executable, such as /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.222.b10-0.el7_6.x86_64/jre/bin/java so this doesn't seem to be as easy/straight forward.

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.