We Keep Coding

How to use different java version by alias?

I have some tools that can only be run by java 8. So i downloaded java 8, but now i have two versions of java installed at the same time (os : Ubuntu):
java-1.11.0-openjdk-amd64 1101 /usr/lib/jvm/java-1.11.0-openjdk-amd64
java-1.8.0-openjdk-amd64 1081 /usr/lib/jvm/java-1.8.0-openjdk-amd64
My question is: is it possible to call these both versions by different aliases? For example i type:
"java" to call java 11 (the default) and
"java8" to call java 8

You could do it in a couple of ways. The easiest way would be to put the following 2 lines in your profile initialization file:
alias java='/usr/lib/jvm/java-1.11.0-openjdk-amd64/bin/java'
alias java8='/usr/lib/jvm/java-1.8.0-openjdk-amd64/bin/java'
Other ways are depending on whether you are the admin of the machine or not. You can create soft links like this:
/usr/bin/java -> /usr/lib/jvm/java-1.11.0-openjdk-amd64
(Not recommended since certain tools in your system may depend on /usr/bin/java).
Update: Try to use sdkman if you can. Makes the job of installing java versions and setting up JAVA_HOME env variable simple.

You can do this as well for JAVA_HOME:
alias java8="export JAVA_HOME=`/usr/libexec/java_home -v 1.8`"
alias java11="export JAVA_HOME=`/usr/libexec/java_home -v 11`"
Updated:
To run java directly use:
$ alias java8="`/usr/libexec/java_home -v 1.8`/bin/java"
$ alias java11="`/usr/libexec/java_home -v 11`/bin/java"
$ java8 -version
java version "1.8.0_281"
Java(TM) SE Runtime Environment (build 1.8.0_281-b09)
Java HotSpot(TM) 64-Bit Server VM (build 25.281-b09, mixed mode)
$ java11 -version
openjdk version "11.0.2" 2019-01-15
OpenJDK Runtime Environment 18.9 (build 11.0.2+9)
OpenJDK 64-Bit Server VM 18.9 (build 11.0.2+9, mixed mode)
You can hardcode your path as well.

I have some tools that can only be run by java 8. So I downloaded java 8, but now I have two versions of java installed at the same time (os : Ubuntu).
You could do this using aliases (see other answers) but this has the problem that only a shell will respect an alias ... and then only if it has the alias defined or loaded by the shell:
Aliases are not inherited via the environment.
Whether a tool's launch script will see the aliases will typically depend on whether you put the alias definitions into the correct shell init file.
It is also possible that an application's launch script will assume that java8 or java11 is a genuine (absolute or relative) pathname, and try to resolve it via the file system.
In short, there is a good chance that using an alias won't work in your use-case.
So a better idea is to arrange that the appropriate Java is on the Command Search Path. You could do this a number of different ways:
You could use the Ubuntu "alternatives" system to globally switch between Java 8 and Java 11.
You could update the PATH variable so that (for example) the Java 11 executables come before the Java 8 executables. This could be done in shell init files (per user or globally), in the application launch scripts ... or by hand.
You could even replace "/usr/bin/java" or whatever with a direct symlink to the version you want to use. (This is crude, and I wouldn't recommend it.) Note that the Java command entries in "/usr/bin" are probably already symlinks.)

How to change the version of Java that CDH uses

I currently have CDH 5 installed on CentOS 6.5 with java jdk1.7 and I am trying to get CDH to use jdk1.8.
I do know that Java 1.8 is not a recommended version of CDH, but it is only a test cluster, so it isn't a big deal.
I have installed both Java 1.7 and Java 1.8 from Oracle's website using the RPM installation, so both versions of Java are currently under /usr/java. Using ls -ld my Java directory looks like:
/usr/java/default -> /usr/java/latest
/usr/java/jdk1.7.0_75
/usr/java/jdk1.8.0_31
/usr/java/latest -> /usr/java/jdk1.8.0_31
I also have script set up in /etc/profile.d to set $JAVA_HOME to /usr/java/default. The contents of my profile.d script:
export JAVA_HOME=/usr/java/default
export PATH=${JAVA_HOME}/bin:${PATH}
So when felt that I have this right, I run:
$ which java
/usr/java/default/bin/java
Telling me that it is pointing to the version of Java symlinked in default. And to determine which version of java is running, I run:
$ java -version
java version "1.8.0_31"
Java(TM) SE Runtime Environment (build 1.8.0_31-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.31-b07, mixed mode)
And I can see that I have Java 1.8 currently running.
Everything seems great, except when I try to start a Hadoop service. The easiest to start is ZooKeeper, because it only has one service. HDFS has multiple servers so it is more work that to just start and stop ZooKeeper.
Starting ZooKeeper is done with the following command:
$ sudo service zookeeper-server start
Then to check which version of java it is running, I search the running processes list for java:
$ ps -ef | grep java
495 7170 1 7 12:27 ? 00:00:00 /usr/java/jdk1.7.0_75/bin/java -Dzookeeper.datadir.autocreate=false -Dzookeeper.log.dir=/var/log/zookeeper -Dzookeeper.root.logger=INFO,ROLLINGFILE -cp /usr/lib/zookeeper/bin/../build/classes:/usr/lib/zookeeper/bin/../build/lib/*.jar:/usr/lib/zookeeper/bin/../lib/slf4j-log4j12.jar:/usr/lib/zookeeper/bin/../lib/slf4j-log4j12-1.7.5.jar:/usr/lib/zookeeper/bin/../lib/slf4j-api-1.7.5.jar:/usr/lib/zookeeper/bin/../lib/netty-3.2.2.Final.jar:/usr/lib/zookeeper/bin/../lib/log4j-1.2.16.jar:/usr/lib/zookeeper/bin/../lib/jline-0.9.94.jar:/usr/lib/zookeeper/bin/../zookeeper-3.4.5-cdh5.3.0.jar:/usr/lib/zookeeper/bin/../src/java/lib/*.jar:/etc/zookeeper/conf::/etc/zookeeper/conf:/usr/lib/zookeeper/*:/usr/lib/zookeeper/lib/* -Dzookeeper.log.threshold=INFO -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.local.only=false org.apache.zookeeper.server.quorum.QuorumPeerMain /etc/zookeeper/conf/zoo.cfg
I know that runs off the screen, bu the important part is that Zookeeper is being started by /usr/java/jdk1.7.0_75/bin/java.
To fix this, I have tried a few things:
Looking at the conf files for Hadoop and ZooKeeper under /etc/hadoop/conf and /etc/zookeeper/conf, respectively.
I found nothing setting JAVA_HOME.
Looking at the /usr/bin/zookeeper script to see if JAVA_HOME was set elsewhere,
I did find the script /usr/lib/bigtop-utils/bigtop-detect-javahome has the ability to set JAVA_HOME, but my profile.d script overrides that.
Manually moving /usr/java/jdk1.7 to /tmp.
Sadly, this is the only thing that works. When I move the jdk1.7 dir to another directory, and start ZooKeeper, it will use Java 1.8. Moving the jdk1.7 dir back, reverts to ZooKeeper using Java 1.7.
Has anyone dealt with this problem and does anyone know how to deal with this? I feel that I have Java set up correctly, but something is telling ZooKeeper/Hadoop to use an old version of Java?

I came here because I was looking for ways to upgrade JDK from 1.7 to 1.8 on the latest Coudera QuickStart VM 5.8 (can't believe they still ship it with JDK1.7 by default!). The hints and suggestions in the above answers helped tremendously - but since they were not listing complete steps to achieve the upgrade - I thought I would add that to help others like me.
So, here is a complete set of steps to upgrade Cloudera QuickStart VM from JDK1.7 to 1.8:
check your current JDK version - out-of-the-box it is:
[cloudera#quickstart ~]$ java -version
java version "1.7.0_67"
Java(TM) SE Runtime Environment (build 1.7.0_67-b01)
Java HotSpot(TM) 64-Bit Server VM (build 24.65-b04, mixed mode)
download desired version of JDK1.8.xx - in my case: jdk-8u111-linux-x64.tar.gz
as user 'cloudera':
untar and move the resulting jdk1.8.0_111 dir to the /usr/java dir:
tar xzf jdk-8u111-linux-x64.tar.gz
sudo mv -f jdk1.8.0_111 /usr/java
shutdown all Hadoop services:
$ for x in `cd /etc/init.d ; ls hadoop-*` ; do sudo service $x stop ; done
update bigtop-utils file - set JAVA_HOME to your new JDK:
sudo vi /etc/default/bigtop-utils
updated lines:
# Override JAVA_HOME detection for all bigtop packages
export JAVA_HOME=/usr/java/jdk1.8.0_111
update 'cloudera' user's .bash_profile - export JAVA_HOME and add update PATH:
export JAVA_HOME=/usr/java/jdk1.8.0_111
PATH=$JAVA_HOME/bin:$PATH:$HOME/bin
export PATH
restart your VM
check Java version - should be the 1.8 one now:
[cloudera#quickstart ~]$ java -version
java version "1.8.0_111"
Java(TM) SE Runtime Environment (build 1.8.0_111-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.111-b14, mixed mode)
By the way, I did not setup the /usr/java/default with the 'latest' sym link as #milk3422 did, for the sake of simplicity, but it would have worked just as well.
thanks!

I hate to answer my own questions, but here is the answer:
The wrong version of $JAVA_HOME is getting set for 2 reasons:
Using the command service removes most environmental variables. From man service:
service runs a System V init script in as predictable environment as
possible, removing most environment variables and with current work-
ing directory set to /.
The /usr/lib/bigtop-utils/bigtop-detect-javahome script has the ability to be configured with the environment variable BIGTOP_JAVA_MAJOR to manually set which version of Java to use. I tried setting this as an environment variable, but service removes it :(. It is also important to note that this script will find all versions of java installed, but the order of preference is Java 6, Java 7, Java 8, Open Java. So if you have Java 6, and 8 installed, it will prefer 6 over 8.
In short, to fix my problem, I added the following to the top of /usr/lib/bigtop-utils/bigtop-detect-javahome:
BIGTOP_JAVA_MAJOR=8
You can also set JAVA_HOME in this file to specify a specific version or path.

I had the same problem. I set
JAVA_HOME=... below the file /usr/lib/bigtop-utils/bigtop-detect-javahome
to override the default detect value. That works great!

Java is configurable in the web UI. Open Cloudera Manger --> Hosts --> Configurations --> Advanced, then set the JAVA HOME. This overrides the CDH's Java detection mechanism.

how to tell which java version cgywin use?

i have cgywin and java 7 installed on window 7, also updated the system environment variable to point to the right java version, however when I run commands in cgywin, I m not sure which java it use, here is the commands and results:
$ java -version
java version "1.7.0_09"
Java(TM) SE Runtime Environment (build 1.7.0_09-b05)
Java HotSpot(TM) Client VM (build 23.5-b02, mixed mode)
$ javac -version
javac 1.7.0_17
$ which java
/cygdrive/c/Windows/system32/java
export
declare -x JAVA_HOME="C:\\Program Files\\Java\\jdk1.7.0_17"
why all the versions are different?

Your PATH has two directories where it can find java one is under windows which picks a version installed (I imagine using the registry) and another is in your JDK. There is no javac in your Windows directory so it finds the on in your JDK.
To keep things simple I would just have one version of Java 7 JDK installed unless you really need multiple versions. I would change your path so it have the version of Java you want first, rather than near the end.

Cygwin runs wrong version of java

I have this problem with Cygwin. I have Java 1.6 and 1.7 installed. I want to use maven 3.0.4 with Java 1.7 but I don't want to uninstall Java 1.6. My JAVA_HOME looks like:
C:\Program Files\Java\jdk1.7.0_09
when I run
java -version
in Cygwin I get:
java version "1.6.0_29"
Java(TM) SE Runtime Environment (build 1.6.0_29-b11)
Java HotSpot(TM) 64-Bit Server VM (build 20.4-b02, mixed mode)
when I run the same command in cmd.exe I get:
java version "1.7.0_09"
Java(TM) SE Runtime Environment (build 1.7.0_09-b05)
Java HotSpot(TM) 64-Bit Server VM (build 23.5-b02, mixed mode)
Does anyone knows how to solve this?

There are two separate questions here.
The first question is why java -version is finding different Java installations on Cygwin and the classical Windows command interpreter.
The answer is most likely that your Cygwin and Windows environments have different values for $PATH and %PATH% respectively. If you want java -version on Cygwin to run Java 7, you need to make sure that the Cygwin $PATH includes the Java 7 bin directory ... in the appropriate syntax.
The second question is how to get the mvn command under Cygwin to use Java 7.
The answer is not so straight-forward:
Setting $PATH might solve your problem.
According to the Maven installation documentation, the mvn wrapper scripts should use the $JAVA_HOME environment variable in your (Cygwin) shell to decide on which Java to use.
The way to find out what is really going on is to look at the wrapper scripts and see what they are actually doing. And if reading the scripts is too hard, try "hacking" the scripts to include set -vx. That will tell you what lines of the script are being read, and what commands are being executed.
Finally, the POM file can influence the source and target levels for your build ... independently of the JVM that runs the build.

Why this version of java?

On my Red Hat server, java -version outputs;
$ java -version
java version "1.6.0_27"
Java(TM) SE Runtime Environment (build 1.6.0_27-b07)
Java HotSpot(TM) 64-Bit Server VM (build 20.2-b06, mixed mode)
$
However, neither PATH, nor JAVA_HOME environment variables are set. Likewise, JAVA_HOME is not set on ~/.bash* files.
Why and how my server uses this version of Java while two other versions of Java are installed as well?

Firstly, JAVA_HOME is not involved in this. (JAVA_HOME is used conventionally by wrapper scripts, etc for applications that use Java ... but not by any of the Java executables themselves.)
Second, you are probably running java via a symlink managed by the alternatives program. (RHEL and similar distros use this utility to allow you to select different versions of utilities installed on the same system.)
Either way, running the following will help you figure out what is going on.
$ ls -l `which java`
(Then following the chain of symlinks until you get to the actual executable.)

Which executable runs depends on PATH variable. Double check it. It can't run if not set it is impossible unless you have some strange Linux config.
If Java executable is in current directory, it would run by ./java. Since it runs with just java it is somewhere in the PATH.