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).
Related
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.
I recently updated my java version to "Java 8 update 77".
As far as i know, this is the newest version...
My Java Control Panel prints the same information,
but when i switch to terminal to verify the java version:
java -version
it outputs:
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)
When i type:
/Library/Internet\ Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/bin/java -version
it prints correctly:
java version "1.8.0_77"
Java(TM) SE Runtime Environment (build 1.8.0_77-b03)
Java HotSpot(TM) 64-Bit Server VM (build 25.77-b03, mixed mode)
So, did i anything wrong?
Why are there two different versions listed ?
Thanks and Greetings!
When Java is updated, it doesn't override the older version. It keeps the older version and also installs new version.
You have to change your $JAVA_HOME environment variable if you want to use new version.
This Link May help
Open the terminal. Type...
nano ~/.bash_profile
Search for export JAVA_HOME. When you find the line, comment it out by placing a # in front of the line.
Type on the next line...
export JAVA_HOME=/Library/Java/JavaVirtualMachines/jdk1.8.0_77.jdk/Contents/Home
assuming that is where the jdk is. Press ctrl+o, ctrl+x.
Type source ~/.bash_profile. And you should be all set.
The second option that you have written about is where you are checking the java applet plugin version which does not need to be the same as the jdk runtime environment.
To make your .bash_profile future proof, you can try this
export JAVA_HOME="$(/usr/libexec/java_home)"
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.
Eclipse complains: JRE version is 1.6.0; version 1.7.0 or later is needed to run Google Plugin for Eclipse.
In the Terminal, java concurs:
> java -version
java version "1.6.0_65"
Java(TM) SE Runtime Environment (build 1.6.0_65-b14-462-11M4609)
Java HotSpot(TM) 64-Bit Server VM (build 20.65-b04-462, mixed mode)
But in System Preferences \ Java \ the Java Control Panel says Your system has the recommended version of Java: Java 7 Update 51
and points to /Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/bin/java.
Eclipse preferences show that the installed JRE is at:
/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home
To point Eclipse to Java 7 (1.7.0), it's enough to change the preference:
What is the source of the discrepancy in Java versions? Is this an instance of having different PATHs between the command-line Mac and the windowed-Mac?
Edit
If I edit /usr/local/adt-bundle-mac-x86_64/eclipse/Eclipse.app/Contents/MacOS/eclipse.ini by adding
-vm
"/Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/bin/java"
Eclipse refuses to start.
And yet this is indeed 1.7:
> "/Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/bin/java" -version
java version "1.7.0_51"
Java(TM) SE Runtime Environment (build 1.7.0_51-b13)
Java HotSpot(TM) 64-Bit Server VM (build 24.51-b03, mixed mode)
If you want to be certain of the JVM that is used to run Eclipse, you need to specify it in your eclipse.ini file, according to these instructions.
Installing this update might fix your problem:
http://support.apple.com/kb/dl1572
In my BAT file I would like to have something like:
set javaVersion=...
if %javaVersion% equ 32 (
echo "do 32 Java routine"
) else (
echo "do non-32 Java routine"
)
On a 64bit machine, with JRE 64bit installed, in the registry under HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment and HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment\1.6 I see almost the same values as on a 32bit machine with JRE 32bit installed:
HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment
CurrentVersion: 1.6
Java6FamilyVersion: 1.6.0_26
HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment\1.6
JavaHome: C:\Program Files\Java\jre6
MicroVersion: 0
RuntimeLib: C:\Program Files\Java\jre6\bin\client\jvm.dll
Therefore, I could check if it is 64bit Java by checking if PROGRAMFILES(X86) is defined and if JavaHome points to location which starts with C:\Program Files\.
But is there a better option?
Actually, the 32-Bit Server does not output "32-Bit". On my system (32-bit Kubuntu), I get the following java -versionoutput:
java version "1.6.0_26"
Java(TM) SE Runtime Environment (build 1.6.0_26-b03)
Java HotSpot(TM) Server VM (build 20.1-b02, mixed mode)
Therefore, it's a better idea to just test for absence of 64-Bit, instead of presence of either.
You could capture the output of java -version - it's in there.
Here's the output on my mac:
java version "1.6.0_26"
Java(TM) SE Runtime Environment (build 1.6.0_26-b03-384-10M3425)
Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02-384, mixed mode)
You should find either "64-Bit" or "32-Bit" in the output.
If you just need to know if there is Java available then run a small class doing something with the default java command.
If you need to know which libraries to use, then instead of poking around the registry then run a small class which tries to call native code in your libraries and let the bat file know if it went well, and run it once for each of your supported platforms.
If none works, then report that. If one or more works then choose the one you like best and use that.
In other words: Explicitly test for what you need to know. Any assumptions will eventually fail.
The simplest way to do this is to parse the exit code of java -d64 -version.
For 64-bit JDK, it would be 0, for 32-bit: 1.
So, you may introduce new variable java64bit:
java -d64 -version >NUL 2>NUL
set java64bit=%ERRORLEVEL%