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.)
Related
My os is Ubuntu 16.04 LTS.
$ cat /etc/profile # part content of this file
JAVA_HOME=/usr/local/java/jdk1.8.0_101
JRE_HOME=$JAVA_HOME/jre
PATH=$PATH:$JAVA_HOME/bin:$JRE_HOME/bin
export JAVA_HOME
export JRE_HOME
export PATH
$ echo $JAVA_HOME
/usr/local/java/jdk1.8.0_101
$ java -version
java version "1.7.0_79"
Java(TM) SE Runtime Environment (build 1.7.0_79-b15)
Java HotSpot(TM) 64-Bit Server VM (build 24.79-b02, mixed mode)
$ ls /usr/local/java/
jdk1.7.0_79/ jdk1.8.0_101/
Why is my java version still jdk7?
Ubuntu has ability to work with multiple java versions. In your case, it just means that it has both JDK 7 and JDK 8 installed in your system but is using JDK 7.
To switch from one java version to another, you can use sudo update-alternatives --config java. This will list all JDKs installed in your system, just enter the number corresponding to JDK 8 and it should switch to JDK 8.
Run which java in your command shell. That will tell you where the java command you are running is coming from.
I suspect that is will tell you "/usr/bin/java" ... because this:
PATH=$PATH:$JAVA_HOME/bin:$JRE_HOME/bin
puts your new bin directories onto the end of the search path, not the beginning.
However, the better way to do this would be to use alternatives as suggested by another Answer. (With a custom installation in "/usr/local" this will require some fiddling around to get "alternatives" to understand the alternative.)
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.
I'm getting the error to run the script "ec2-describe-regions"
$ec2-describe-regions
/usr/local/ec2/ec2-api-tools-1.6.14.1/bin/ec2-cmd: line 62: /usr/lib/jvm/java-7-openjdk-amd64/jre/bin/java/bin/java: Not a directory
Before it, I did followings:
Open a terminal on my personal computer.
Install Java.
Create security credentials (an X.509 certificate and private key).
Set up a few environment variables.
Run my first command.
Here is the information I did:
$which java
/usr/bin/java
$echo $EC2_HOME
/usr/local/ec2/ec2-api-tools-1.6.14.1
$echo $JAVA_HOME
/usr/lib/jvm/java-7-openjdk-amd64/jre/bin/java
$java -version
java version "1.7.0_55"
OpenJDK Runtime Environment (IcedTea 2.4.7) (7u55-2.4.7-1ubuntu1)
OpenJDK 64-Bit Server VM (build 24.51-b03, mixed mode)
Try the following:
mv /usr/bin/java /usr/bin/java.orig
ln -s /usr/lib/jvm/java-7-openjdk-amd64/jre/bin/java /usr/bin/java
You may have two or more java instances on your server. Make sure you use the same java executable where your JAVA_HOME points to.
This command uses the old CLI tools, i'd recommend you use the new, unified and greatly improved CLI:
https://aws.amazon.com/cli/
I started off with CentOS and OpenJDK 1.7
# java -version
java version "1.7.0_25"
OpenJDK Runtime Environment (rhel-2.3.10.4.el6_4-x86_64)
OpenJDK 64-Bit Server VM (build 23.7-b01, mixed mode)
In order to run a specific application, I want to use Oracle's Java 1.6, provided from an RPM.
I copied the Oracle binary to a specific new directory:
# pwd
/oracleJava/jdk-6u45-linux-x64-rpm
I extracted the binary and it gave me the following files:
# ls
jdk-6u45-linux-amd64.rpm
sun-javadb-core-10.6.2-1.1.i386.rpm sun-javadb-javadoc-10.6.2-1.1.i386.rpm
sun-javadb-client-10.6.2-1.1.i386.rpm sun-javadb-demo-10.6.2-1.1.i386.rpm
sun-javadb-common-10.6.2-1.1.i386.rpm sun-javadb-docs-10.6.2-1.1.i386.rpm
I installed the RPM and the rpm utility believes that it installed properly:
rpm -q jdk
jdk-1.6.0_45-fcs.x86_64
# rpm -Uvh ./*.rpm
Preparing... ########################################### [100%]
package jdk-2000:1.6.0_45-fcs.x86_64 is already installed
# rpm -Uvh sun-javadb-*.rpm
[I omit the feedback because it generates a formatting error]
#
However, the Java version just shows 1.7
# java -version
java version "1.7.0_25"
OpenJDK Runtime Environment (rhel-2.3.10.4.el6_4-x86_64)
OpenJDK 64-Bit Server VM (build 23.7-b01, mixed mode)
In other words, I was expecting the Oracle files to give me some new /java directory somewhere, with a new java executable that would return a different answer for "java -version"
I need that new directory so that I can set JAVA_HOME and use the 1.6 version of Java.
Helpful suggestions would be greatly appreciated. Thanks in advance.
The Oracle JDK RPMs are horrible.
They do not register with the alternatives system.
They do not Provide (in RPM terms) "java"
They have messed up their RPM 'version string' and rely on Epoch (...)
All versions of the JDK (i.e. 1.6 vs 1.7) have the same Epoch
In order to quickly remedy your problem you can run the following:
/usr/sbin/alternatives --install /usr/bin/java java /usr/java/default/bin/java 20000
It will register and prefer the Oracle java installation as an alternative. OpenJDK has weight 16000; here we register with 20000. Once you've run this command you can switch between java versions by using the (already mentioned) alternatives --config java command.
As for a less quick fix you can use my virtual java package. It's quite possibly not perfect (I'm open for improvements ;) ), but it Provides java (making my apache-tomcat package happy) and registers with the alternatives system. This virtual package simply depends on jdk...you can find it here: https://github.com/keystep/virtual-java-rpm
Run the following command to see if your JVM is getting listed.
sudo update-alternatives --config java
If your JVM gets listed select it.
The problem is that Oracle's RPMs are (wilfully IMO!) ignorant of the "alternatives" system.
Instead, they install stuff in a non-standard place (/usr/java) and then expect the user / system administrator to mess with the PATH variable ... by hand.
It is a nuisance!
So what has probably happened in your case is that your JDK / JRE has been installed in a subdirectory of /usr/java ... but since you haven't added the relevant bin subdirectory to the front of your PATH you are still picking up the OpenJDK tools via the java command name.
You can fix this after the fact by using "alternatives" to configure and then select the Oracle commands. But it is messy, especially if you want the JDK tools as well. (There are a lot of them!)
Please check that whether your JAVA_HOME points to JDK 6 using echo $JAVA_HOME. In order change your JAVA_VERSION to Java 6, you need to point to the Java development KIT 6. You also need to add the bin directory to the $PATH variable. Please ensure that JDK6 bin directory comes in the $PATH prior to other JDK bin,if any. You can check the version of your Java in the environment by command java -version.The other answer by learningloop is very perfect to switch between different Java configurations
Try to the following method
delete OpenJDK folder from
/usr/lib/jvm
I had same problem and got solution through this method
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.