I am currently with installing and integrating a couple of software on Linux, and I'm very new to Linux. One of the software refuses to run and instructs me to properly set $JAVA_HOME. But I have set $JAVA_HOME! However, when I check the $JAVA_HOME and java -version tests to see if I have done it correctly, it only produces the correct answer when I'm logged in as opc. The permissions of the software I am trying to install is oracle. Do I need to set $JAVA_HOME again when I'm logged in as oracle? And why?
[opc#mydir ~]$ $JAVA_HOME
-bash: /u01/jdk-11.0.3/: Is a directory
[opc#mydir ~]$ java -version
java version "11.0.3" 2019-04-16 LTS
Java(TM) SE Runtime Environment 18.9 (build 11.0.3+12-LTS)
Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.3+12-LTS, mixed mode)
[opc#mydir ~]$ sudo su oracle
[oracle#mydir opc]$ $JAVA_HOME
[oracle#mydir opc]$ java -version
bash: java: command not found
Environment variables (such as $JAVA_HOME) are set per process. For shells, you'd usually have some initialization script (like .bashrc) that sets all the relevant variables for the current session. You should copy the initialization of $JAVA_HOME you have in the opc user to the oracle user too.
Related
tl,dr;
Doing export JAVA_HOME=$(/usr/libexec/java_home -v 14) once JAVA_HOME was already set won't change active java
Steps
set JAVA_HOME first (for example with export JAVA_HOME=$(/usr/libexec/java_home -v 11)):
$ echo ${JAVA_HOME}
/Library/Java/JavaVirtualMachines/adoptopenjdk-11.jdk/Contents/Home
$ java -version
openjdk version "11.0.8" 2020-07-14
OpenJDK Runtime Environment AdoptOpenJDK (build 11.0.8+10)
OpenJDK 64-Bit Server VM AdoptOpenJDK (build 11.0.8+10, mixed mode)
Try to set it to different version (for example export JAVA_HOME=$(/usr/libexec/java_home -v 14)) - it still uses previously set java (even though JAVA_HOME was updated):
$ echo ${JAVA_HOME}
/Library/Java/JavaVirtualMachines/adoptopenjdk-14.jdk/Contents/Home
$ java -version
openjdk version "11.0.8" 2020-07-14
OpenJDK Runtime Environment AdoptOpenJDK (build 11.0.8+10)
OpenJDK 64-Bit Server VM AdoptOpenJDK (build 11.0.8+10, mixed mode)
I'm not sure why it's not working now - it was working just fine a while back (I'd say 2-3 months ago)
There is a seemingly similar topic (Can't set JAVA_HOME on Catalina) but it boils down to different shell. In my case I'm using same shell - bash from brew:
$ bash -version
GNU bash, version 5.0.18(1)-release (x86_64-apple-darwin19.5.0)
Copyright (C) 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Seems update JAVA_HOME is not getting reflected in PATH variable.
So, please update PATH variable also and keep the updated JAVA_HOME as the first element in the export PATH command
OK, I finally managed to solve the issue. As other have pointed out, everything has to do with PATH variable. And I indeed had JAVA_HOME/bin in there… which causes the problem. Today during an update I notice that openjdk brew formula had this comment:
keg_only "it shadows the macOS `java` wrapper"
And things immediately "clicked". After searching a bit I found Why isn't java wrapper not picking up the right version specified in JAVA_HOME on macOS? which confirmed the issue. By including JAVA_HOME in the PATH in my .profile file I was breaking native macOS functionality of it's java wrapper, which selects active java version based on currently set JAVA_HOME.
This is my example session (from opening the shell and having export JAVA_HOME=$(/usr/libexec/java_home -v 11) in the .profile file) -- I have default from the profile, then I set explicitly JAVA_HOME and it switches java version on the fly:
$ java -version
openjdk version "11.0.8" 2020-07-14
OpenJDK Runtime Environment AdoptOpenJDK (build 11.0.8+10)
OpenJDK 64-Bit Server VM AdoptOpenJDK (build 11.0.8+10, mixed mode)
$ export JAVA_HOME=$(/usr/libexec/java_home -v 14)
$ java -version
openjdk version "14.0.2" 2020-07-14
OpenJDK Runtime Environment AdoptOpenJDK (build 14.0.2+12)
OpenJDK 64-Bit Server VM AdoptOpenJDK (build 14.0.2+12, mixed mode, sharing)
Running Cassandra
$ apache-cassandra-3.11.1/bin/cassandra -f -R
Unable to find java executable. Check JAVA_HOME and PATH environment variables.
Java Settings are
java -version
openjdk version "1.8.0_121"
OpenJDK Runtime Environment (Zulu 8.20.0.5-linux64) (build 1.8.0_121-b15)
OpenJDK 64-Bit Server VM (Zulu 8.20.0.5-linux64) (build 25.121-b15, mixed mode)
whereis java
java: /usr/bin/java /usr/lib/java /etc/java /usr/share/java /data/ytbigdata/anaconda3/bin/java
which java
~/anaconda3/bin/java
~/.bash_profile setting
export JAVA_HOME=/data/ytbigdata/anaconda3/bin/java
export PATH=$JAVA_HOME/bin:$PATH
The Cassandra documentation says "On the Cassandra nodes where the agents are installed, create the file /etc/default/datastax-agent and set the environment variables for JAVA_HOME and any other custom environment variables that the agent might need." https://docs.datastax.com/en/opscenter/6.1/opsc/install/opscCustomVariables_t.html
I am aware this might look duplicated, but I don't seem to find the answer that I am seeking (perhaps is too trivial).
I just downloaded java from the oracle site and I read this:
$java -version
java version "1.8.0_91"
Java(TM) SE Runtime Environment (build 1.8.0_91-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.91-b14, mixed mode)
Then I added this to my .bash_profile file:
# Java
export JAVA_HOME="`/usr/libexec/java_home -v 1.8`"
so that:
$ echo $JAVA_HOME
/Library/Java/JavaVirtualMachines/jdk1.8.0_91.jdk/Contents/Home
So far so good.
Now when I type:
$ which java
/usr/bin/Java
Which I think is the default installation (?, I really have no experience in Java)
At this stage, I don't know if I have to simlink:
sudo ln -s /Library/Java/JavaVirtualMachines/jdk1.8.0_91.jdk/Contents/Home/bin/java /usr/bin
or if the simlink was establish during the java installation. I am going to start installing a series of things that depend on java, so I would like to make sure I understand this before moving on.
Thanks!
What you've done will work. From my system:
$ /usr/bin/java -version
java version "1.8.0_92"
Java(TM) SE Runtime Environment (build 1.8.0_92-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.92-b14, mixed mode)
It uses the java_home command you used, which depends on the Java part of the System Preferences application. So if somehow you have the "wrong" version in use, you can fix it there. But by default, it seems in my experience to use the latest version (man java_home doesn't really say).
Please see these 3 commands and their outcomes in MacOS:
Korays-MacBook-Pro:~ koraytugay$ /usr/libexec/java_home
/Library/Java/JavaVirtualMachines/jdk1.8.0_11.jdk/Contents/Home
Korays-MacBook-Pro:~ koraytugay$ java -version
java version "1.7.0_55"
Java(TM) SE Runtime Environment (build 1.7.0_55-b13)
Java HotSpot(TM) 64-Bit Server VM (build 24.55-b03, mixed mode)
Korays-MacBook-Pro:~ koraytugay$ echo $JAVA_HOME
/Library/Java/JavaVirtualMachines/jdk1.7.0_55.jdk/Contents/Home
Why does the first one return 1.8? What exactly is /libexec/java_home ?
Koray,
As per the Oracle docs...
JAVA_HOME is just an environment variable used to trigger the 'java' found in your PATH to use a different JDK image. Unfortunately, not all 'java' startup scripts obey this env variable. It's also used by many java tool startup scripts to determine what 'java' to run, bypassing the 'java' found in the PATH setting. Setting this variable during a JDK build is a bad idea, don't do it.
I use Eclipse myself, and don't have a JAVA_HOME env variable defined, here is my output running the same commands.
brandon#brandons-mbp ~
$ /usr/libexec/java_home
/Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk/Contents/Home
brandon#brandons-mbp ~
$ java -version
java version "1.8.0_05"
Java(TM) SE Runtime Environment (build 1.8.0_05-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.5-b02, mixed mode)
brandon#brandons-mbp ~
$ echo $JAVA_HOME
Not sure why you have two different versions but did you try updating your JDK recently? Maybe when you upgraded it failed to launch a script to update your $JAVA_HOME.
Here's the instructions for installing JDK and setting JAVA_HOME on *nix based OSes.
Let me know if that helps I can help you dig deeper if need be.
Is it possible to specify the JVM to use when you call "java jar jar_name.jar" . I have two JVM installed on my machine. I can not change JAVA_HOME as it may break code that is all ready running.
Kind Regards
Stephen
Yes - just explicitly provide the path to java.exe. For instance:
c:\Users\Jon\Test>"c:\Program Files\java\jdk1.6.0_03\bin\java.exe" -version
java version "1.6.0_03"
Java(TM) SE Runtime Environment (build 1.6.0_03-b05)
Java HotSpot(TM) Client VM (build 1.6.0_03-b05, mixed mode, sharing)
c:\Users\Jon\Test>"c:\Program Files\java\jdk1.6.0_12\bin\java.exe" -version
java version "1.6.0_12"
Java(TM) SE Runtime Environment (build 1.6.0_12-b04)
Java HotSpot(TM) Client VM (build 11.2-b01, mixed mode, sharing)
The easiest way to do this for a running command shell is something like:
set PATH=c:\Program Files\Java\jdk1.6.0_03\bin;%PATH%
For example, here's a complete session showing my default JVM, then the change to the path, then the new one:
c:\Users\Jon\Test>java -version
java version "1.6.0_12"
Java(TM) SE Runtime Environment (build 1.6.0_12-b04)
Java HotSpot(TM) Client VM (build 11.2-b01, mixed mode, sharing)
c:\Users\Jon\Test>set PATH=c:\Program Files\Java\jdk1.6.0_03\bin;%PATH%
c:\Users\Jon\Test>java -version
java version "1.6.0_03"
Java(TM) SE Runtime Environment (build 1.6.0_03-b05)
Java HotSpot(TM) Client VM (build 1.6.0_03-b05, mixed mode, sharing)
This won't change programs which explicitly use JAVA_HOME though.
Note that if you get the wrong directory in the path - including one that doesn't exist - you won't get any errors, it will effectively just be ignored.
You should be able to do this via the command line arguments, assuming these are Sun VMs installed using the usual Windows InstallShield mechanisms with the JVM finder EXE in system32.
Type java -help for the options. In particular, see:
-version:<value>
require the specified version to run
-jre-restrict-search | -jre-no-restrict-search
include/exclude user private JREs in the version search
yes I often need to have 3 or more JVM's installed. For example, I've noticed that sometimes the JRE is slightly different to the JDK version of the JRE.
My go to solution on Windows for a bit of 'packaging' is something like this:
#echo off
setlocal
#rem _________________________
#rem
#set JAVA_HOME=b:\lang\java\jdk\v1.6\u45\x64\jre
#rem
#set JAVA_EXE=%JAVA_HOME%\bin\java
#set VER=test
#set WRK=%~d0%~p0%VER%
#rem
#pushd %WRK%
cd
#echo.
#echo %JAVA_EXE% -jar %WRK%\openmrs-standalone.jar
%JAVA_EXE% -jar %WRK%\openmrs-standalone.jar
#rem
#rem _________________________
popd
endlocal
#exit /b
I think it is straightforward. The main thing is the setlocal and endlocal give your app a "personal environment" for what ever it does -- even if there's other programs to run.
If you have 2 installations of the JVM.
Place the version upfront.
Linux : export PATH=/usr/lib/jvm/java-8-oracle/bin:$PATH
This eliminates the ambiguity.