I have set up Java in Windows environment variable, but when I type java -version it is not taking the path specified.
So the user path has
%JAVA_HOME%\bin
And the value of JAVA HOME is
M:\java\java-se-8u41-ri // this points to jdk 8
When I type java -version, I get
java version "1.8.0_301"
Java(TM) SE Runtime Environment (build 1.8.0_301-b09)
Java HotSpot(TM) Client VM (build 25.301-b09, mixed mode, sharing)
This is not JDK. Why is this happening and how can I solve it?
EDIT : this is what i'm expecting
openjdk version "1.8.0_41"
OpenJDK Runtime Environment (build 1.8.0_41-b04)
OpenJDK Client VM (build 25.40-b25, mixed mode)
EDIT 2
information requested
echo %JAVA_HOME%
M:\java\java-se-8u41-ri
where java
C:\Program Files (x86)\Common Files\Oracle\Java\javapath\java.exe
M:\java\java-se-8u41-ri\bin\java.exe
echo %PATH%
C:\Program Files (x86)\Common Files\Oracle\Java\javapath;C:\Windows\system32;C:\Windows;C:\Program Files\PostgreSQL\13\bin;C:\Program Files\PostgreSQL\13\lib;C:\Program Files\nodejs\;M:\java\java-se-8u41-ri\bin;C:\Program Files\nodejs;C:\Program Files\sfdx\bin;M:\maven\apache-maven-3.8.3\bin;
First, a great thanks to #Mark Rotteveel and #Christian.
The issue was there were multiple Java installations (as visible in where java).
The path variable was pointing to Oracle Java at first and was ignoring the Java that I wanted it to point, once I removed it from the path, it started working fine.
Related
Hi right now on my PC works java 17
C:\Users\Dom>java -version
java version "17.0.4.1" 2022-08-18 LTS
Java(TM) SE Runtime Environment (build 17.0.4.1+1-LTS-2)
Java HotSpot(TM) 64-Bit Server VM (build 17.0.4.1+1-LTS-2, mixed mode, sharing)
I want swap on Java 8 for it in windows environment variables i change path on C:\Program Files\Java\jdk1.8.0_341\bin (like on one guide) but thats not help.
verison java in my pc
- jdk-17.0.4.1
- jdk1.8.0_202
- jdk1.8.0_341
How i can change my java version on Java 8 ?
SOLUTION
in file i type it:
#echo off
echo Setting JAVA_HOME
set JAVA_HOME=C:\Program Files\Java\jdk1.8.0_341
echo setting PATH
set PATH=C:\Program Files\Java\jdk1.8.0_341\bin;%PATH%
echo Display java version
thats change java version
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.
In an instance of Git Bash, typing in java -version gives me:
Error: could not open 'C:\Program Files (x86)\Java\jre7\lib\i386\jvm.cfg'
However, my actual Java path is in D:\Program Files\Java\jdk1.8.0_45\bin. This is shown in my %PATH% variable if I type in either echo $PATH or env | grep PATH.
Where is Git Bash getting this nonexistent Java path from?
P.S.
To add on to this, running java -version in the Command Prompt gives me the correct output:
java version "1.8.0_45"
Java(TM) SE Runtime Environment (build 1.8.0_45-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.45-b02, mixed mode)
Check if you have some old java.exe, javaw.exe, javaws.exe in the c:/windows/system32 folder, as mentioned in "Java path..Error of jvm.cfg".
I just checked with Git 2.6.3 on Windows, where I don't have anything in c:/windows/system32, and the result is consistent between:
git bash:
vonc#bigvonc MINGW64 /
$ 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)
and CMD:
C:\prgs\git\PortableGit-2.6.3-64-bit>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)
Both report the same java at the same spot:
vonc#bigvonc MINGW64 /
$ which java
/c/prgs/jdk/jdk-7u51-windows-x64/bin/java
C:\prgs\git\PortableGit-2.6.3-64-bit>which java.exe
C:\prgs\jdk\jdk-7u51-windows-x64\bin\java.exe
Conclusion: upgrade to the latest git for windows.
If you are trying to manually set JDK, then please check if you haven't missed the Oracle Java (C:\ProgramData\Oracle\Java\javapath) in Path Environment Variable under System Variables, remove it and java -version should work just fine.
Check the PATH variable in your .bash_profile file to make sure it reflects the correct version of java. The file is usually in your home directory C:\Users\\{HOME}\\.bash_profile
It will happen when you have running an IDE with another set of JDK instances. The better way to resolve this is set you JDK home in path and make it available in last row. This is working for me.
I'm not sure why my PATH is not being respected regarding where to find java on my MAC OS X 10.9.5.
After searching around I found that the Java version referenced from the command line was at /usr/bin/java, while the Java version referenced by Oracle's tools used by browsers and visible at System Preferences > Java, Open the Java Control Panel, click on Java tab at top, click on View... button, check both User and System tabs for Path, showing in both:
/Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/bin/java
The command line picks up 1.6.0_65 even though that is for the version at /usr/bin rather than the one at /Library/Internet\ Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/bin earlier in the path.
Joes-MacBook-Pro:~ josephmurray$ 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)
Joes-MacBook-Pro:~ josephmurray$ which java
/usr/bin/java
Joes-MacBook-Pro:~ josephmurray$ echo $PATH
/Applications/tr-sub.app/Contents/MacOS:/Library/Internet\ Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/bin:~/civix:/usr/local:/usr/local/bin:/Applications/MAMP/Library/bin:/Applications/MAMP/bin/php/php5.4.19/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/usr/local/git/bin:/usr/X11/bin:/Library/PostgreSQL/9.3/bin/
Joes-MacBook-Pro:~ josephmurray$ /Library/Internet\ Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/bin/java -version
java version "1.8.0_25"
Java(TM) SE Runtime Environment (build 1.8.0_25-b17)
Java HotSpot(TM) 64-Bit Server VM (build 25.25-b02, mixed mode)
Joes-MacBook-Pro:~ josephmurray$ /usr/bin/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)
Joes-MacBook-Pro:~
This is preventing me from installing eclipse because it needs Java to be at least 1.7. How can I fix this?
If you want to work with Eclipse, you need to install a full JDK, not use a JRE. The installed JRE is lacking debug symbols etc.
You can install it from Oracle's Java SE Development Kit download page.
You will then also be able to use command line tools such as javac.
The problem turned out to be using a backslash to escape the space in the path. While using it is necessary when entering a command on the commandline, it should not be included when setting PATH in ~/.bash_profile:
export PATH="/Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/bin:~/civix:/usr/local:/usr/local/bin:/Applications/MAMP/Library/bin:/Applications/MAMP/bin/php/php5.4.19/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/usr/local/git/bin:/usr/X11/bin"
export PATH=/Applications/tr-sub.app/Contents/MacOS:$PATH:/Library/PostgreSQL/9.3/bin/
NB: Each time you edit ~/.bash_profile you need to refresh the environment variables in the shell by running:
$ source ~/.bash_profile
I installed/uninstalled java jre/jdk now many times and finally installed the older version 1.6.0_17 which is now located at "C:\Program Files\Java\jre6\bin". Now after all if I call 'java -version' within R i can see that R is looking for Java at the old path which is now wrong. The question is: Why is R looking for Java at the wrong path even so the windows path is set correctly? There are no double entrys within the windows path as far as I can see and I restarted R as well as Windows more then once since then. Any Ideas where R takes the wrong path from?
On windows shell:
> set
[..]
OS=Windows_NT
Path=C:\Program Files\Java\jre6\bin;
[..]
> java -version
java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) 64-Bit Server VM (build 14.3-b01, mixed mode)
within R:
> system("java -version")
Error: could not open `C:\Program Files (x86)\Java\jre6\lib\i386\jvm.cfg'
You problem depends on 64/32 bit versions.
You run 32-bit R, which use 32-bit command prompt and find 32-bit java. If you use 64-bit R then it runs 64-bit command promt and proper java.
You could check it by run 32-bit command promt (following this post):
Click Start.
Type %windir%\SysWoW64\cmd.exe in Start Search box.
Press Enter.
Type java -version
In my system it fails because I don't have 32-bit java. With standard cmd.exe I get proper path.
For possible solution there are two ways. Install 32-bit R and 32-bit Java or 64-bit R (which is officially supported from 2.11 version) and 64-bit Java. On my system (64-bit Windows 7) I've got both sets, so on 32-bit combination I get:
> system("java -version")
java version "1.6.0_20"
Java(TM) SE Runtime Environment (build 1.6.0_20-b02)
Java HotSpot(TM) Client VM (build 16.3-b01, mixed mode, sharing)
And on 64-bit:
> system("java -version")
java version "1.6.0_18"
Java(TM) SE Runtime Environment (build 1.6.0_18-b07)
Java HotSpot(TM) 64-Bit Server VM (build 16.0-b13, mixed mode)
On 64-bit version you could call 32-bit Java using 32-bit cmd:
shell(
"java -version",
shell = file.path(Sys.getenv("windir"),"SysWoW64/cmd.exe")
)
java version "1.6.0_20"
Java(TM) SE Runtime Environment (build 1.6.0_20-b02)
Java HotSpot(TM) Client VM (build 16.3-b01, mixed mode, sharing)
About Shane's comment I think the question is how R get path to 32-bit cmd. Because I can't find a way to call 64-bit cmd on 32-bit R.
You're assuming that R is looking at the windows path, but the code is telling you that it's not. So check your assumption: R is getting the path somewhere else.
If I open up a command shell on my Windows machine and type "java -version" I get this:
C:\>java -version
java version "1.6.0_13"
Java(TM) SE Runtime Environment (build 1.6.0_13-b03)
Java HotSpot(TM) Client VM (build 11.3-b02, mixed mode, sharing)
If I check the PATH on my machine, I get (edited for clarity):
C:\>set path
Path=;C:\JDKs\jdk1.6.0_13\bin;
If I open up R version 2.8.1 and run system("java -version") I get this:
> system("java -version")
java version "1.6.0_15"
Java(TM) SE Runtime Environment (build 1.6.0_15-b03)
Java HotSpot(TM) Client VM (build 14.1-b02, mixed mode, sharing)
>
So, like I said, R is not using my path to find java.exe. It's using something else.
I got to this page trying to work out why my JDK was reporting 64 bit despite the PATH and JAVA_HOME were pointing to 32 bit.
I dont even know what R is, but this article might help (it solved it for me)
http://www.tipandtrick.net/2008/how-to-open-and-run-32-bit-command-prompt-in-64-bit-x64-windows/
In a nutshell, dont run from 'cmd' use '%windir%\SysWoW64\cmd.exe' instead.
Or, put your JDK at the front of the path instead of the end (I dont think this is ideal).
You may also need to check the registry, R may have its own setting. You can also start regedit and do a search on the path to binary that it is starting.
There is a simple way to check which version of Java you have installed on your computer using the rJava package.
rJava::.jinit()
rJava::.jcall("java.lang.System", "S", "getProperty", "java.version")