I have several versions of Java on my system (OS X El Capitan, version 10.11.6). My current JAVA_HOME variable is set to a Java 8 JDK, and the bin directory is in my path:
$ java -version
java version "1.8.0_121"
Java(TM) SE Runtime Environment (build 1.8.0_121-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.121-b13, mixed mode)
Nevertheless, whenever I try to start Eclipse or STS, I get a crash, and inside the .metadata/.log file in the workspace it includes the line:
java.version=9-ea
I can edit the eclipse.ini file and add a -vm flag to get it to start with the proper JVM, but what mystifies me is where Eclipse is getting the wrong information in the first place. Isn't setting JAVA_HOME enough? Where else might it be finding Java?
I think the native launcher of Eclipse uses /usr/libexec/java_home to determine the current JVM to use and I am not aware of a way to change that command to point to a different VM as a default.
Related
Before marking it duplicate FYI I have already read How can I change the Java Runtime Version on Windows (7)? and How to set path for Jre 6 when jre 7 installed?.
I have both Java7 and Java8 in my machine. I have
JAVA_HOME = C:\Program Files\Java\jdk1.7.0_60
PATH = ...;%JAVA_HOME%\bin;....
but I am getting
C:\>java -version
java version "1.8.0_40"
Java(TM) SE Runtime Environment (build 1.8.0_40-b26)
Java HotSpot(TM) 64-Bit Server VM (build 25.40-b25, mixed mode)
C:\>javac -version
javac 1.7.0_60
I want to set JRE to 1.7 too. How to do that?
You will probably have to edit your path environment variable.
If you want to check what's in your PATH environment variable in an organized fashion, run:
echo %path:;=&echo.%
Make sure the 1.8 is not on the path or if you want it there make sure it appears after 1.7.
To edit it, go to My Computer > Properties > System Properties > Advanced tab > Advanced section > Environment Variables.
Also check what is actually launched when you run java from the command line, run the following command:
where java
It will show you what windows runs when you request java.
To solve the problem, remove or change the name of java.exe and javaw.exe into System32 folder:
Prepend the System Variable's Path with JRE bin's path.
where java did work for me. I found there is another version of java associated with the SPSS (1.8.0). Uninstall SPSS and the problem solved.
The solution that worked for me was:
In "Path" variable replace "C:\ProgramData\Oracle\Java\javapath;" with %JAVA_HOME%\bin where JAVA_HOME variable was set to "C:\Program Files\Java\jdk1.7.0_60"
So, I had always thought there was no difference between the java.exe located in the jdk\bin and that in the jdk\jre\bin folders. Apparently, that is not the case, certainly not with java8 anyway.
I was testing the maverick ssh library and found that it would not auto-negotiate an encryption cipher from the list offered by the sshd server when using the java.exe from jdk\bin. Changing the java.exe used to that from the jre supplied with jdk (in the jdk\jre\bin folder) let the test app work fine.
So... what could possibly explain the difference - why would one java.exe work and the other not, if they are both the same?
They appear the same on the surface:
C:\Program Files\Java\jdk1.8.0_20>dir bin\java.exe
08/22/2014 03:35 PM 190,856 java.exe
C:\Program Files\Java\jdk1.8.0_20>dir jre\bin\java.exe
08/22/2014 03:35 PM 190,856 java.exe
But must be different under the hood:
C:\Program Files\Java\jdk1.8.0_20>diff bin\java.exe jre\bin\java.exe
Files bin\java.exe and jre\bin\java.exe differ
EDIT:
I did review the question which is suggested as a duplicate, however it did not address my question.
The versions of the binaries appear the same:
C:\Program Files\Java\jdk1.8.0_20>bin\java -version
java version "1.8.0_20"
Java(TM) SE Runtime Environment (build 1.8.0_20-b26)
Java HotSpot(TM) 64-Bit Server VM (build 25.20-b23, mixed mode)
C:\Program Files\Java\jdk1.8.0_20>jre\bin\java -version
java version "1.8.0_20"
Java(TM) SE Runtime Environment (build 1.8.0_20-b26)
Java HotSpot(TM) 64-Bit Server VM (build 25.20-b23, mixed mode)
I did not adjust the classpath or anything else on my commandline, other than the path to java.exe.
Compared the two using WinMerge... there are a few diffs nr the start and end (moreso) of the two files. All binary gobble-de-gook to me.
Re using that library and getting different results, that's almost certainly not anything to do with java.exe, but something to do with the classpath and jars used by the JDK install vs. the JRE install.
Re your different files, it's not just you: I dug up a Windows 8.1 machine with (an old copy of) Oracle's Java8 on it, and it's the same thing: Sizes, dates, and versions match, contents don't quite. This isn't true of my Linux box with Oracle's Java8 on it, where the jdk/bin/java and jdk/jre/bin/java files are identical (and not just symlinked). My guess is it relates to optimization defaults, but doesn't relate to your ssh library issue.
My intention is to do a bit of modding of Minecraft using MCP. For that, my Java JDK needs to be specified in the system PATH and working. Unfortunately, it isn't working as typing "java -version" returns the version I use for running Minecraft (JRE7), not the one I've specified in the PATH (JDK6). (Note: JDK6 is supposedly what's needed for this, and the JRE obviously wouldn't work for development anyway.)
Here's my full PATH:
C:\Program Files\Java\jdk1.6.0_45\bin;C:\Program Files (x86)\OpenVPN\bin;C:\Program Files (x86)\Google\google_appengine\
The specified JAVA_HOME:
C:\Program Files\Java\jdk1.6.0_45
And here's the result of "java -version", even after a full system restart since installing the JDK and setting the PATH:
java version "1.7.0_45"
java(TM) SE Runtime Environment (build 1.7.0_45-b18)
java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode)
Help would be massively appreciated, thanks!
x_a_horse_with_no_name's comment got it! I simply renamed java.exe and javaw.exe in C:\Windows\System32 (& in \SysWOW64), thereby forcing Windows to instead read from the PATH. My guess is that the JDK6 install refused to overwrite the JRE7 files as they were newer or something. Regardless, problem solved, thanks!
Eclipse returns this error message when launching:
I am pretty sure that both the java installation and Eclipse are both for my 64-bit system.
Here is my .ini file:
Your version of Eclipse looks OK, based on the filename.
To check your version of Java, run java -version in a console. On Windows 7 with 64-bit Java 6 I get:
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)
Check that this is the version being used by Eclipse, as shown in your error code. If not, call that version explicitly, e.g.
"C:\Program Files (x86)\Java\jre7\bin\java.exe" -version
I moved the
-vm
up below the first openfile, not the second.
PIC:
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.