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
Related
I have a macbook with latest HighSierra installed and from System Preferences / Java Panel. It says that i have got latest Java version installed: java 8 update 181.
From the "Java" tab of the aforementioned "Java settings" dialog i can see that the version 181 it is referring to is installed in /Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/bin/java
If i try to execute that binary (i.e. java -version) i actually get:
java version "1.8.0_181"
Java(TM) SE Runtime Environment (build
1.8.0_181-b13) Java HotSpot(TM) 64-Bit Server VM (build 25.181-b13, mixed mode)
however when i try to launch "java" from a generic prompt or if i try to execute javac i get a different result:
java version "1.8.0_40"
Java(TM) SE Runtime Environment (build 1.8.0_40-b27)
Java HotSpot(TM) 64-Bit Server VM (build 25.40-b25, mixed mode)
this latter java is installed in /System/Library/Frameworks/JavaVM.framework/Versions/Current/Commands/
So it seems to me that i have got a jre (181) and a jdk (40) is this correct?
if so, is this the correct setup on mac? i started to wonder when forticlient analyzer showed up a bunch of CVE security issues related to JDK that are fixed in update 181.
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 have java JDK installed sucessfully in my mac os 10.9 ..
$ 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)
But when i try to run eclipse it asks me to jave SE 6 Runtime again !!!
It looks like eclipse is unable to locate the installed java. You can tell eclipse to point to this version of java by modifying eclipse.ini file
In eclipse.ini file, we need to add -vm option to point to the java8 location:
See: http://wiki.eclipse.org/Eclipse.ini#-vm_value:_Mac_OS_X_Example
I have multiple versions of java installed. Recently while testing I noticed that cygwin and powershell were running different versions, and figured it was a problem with my path, but it looks to be something stranger. In powershell I get:
PS C:\Users\djpeaco> echo $env:JAVA_HOME
PS C:\Users\pavon> where.exe java
C:\Windows\System32\java.exe
PS C:\Users\pavon> C:\Windows\System32\java.exe -version
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)
And then in cygwin (bash):
$ echo $JAVA_HOME
$ which java
/cygdrive/c/Windows/system32/java
$ /cygdrive/c/Windows/system32/java -version
java version "1.7.0_51"
Java(TM) SE Runtime Environment (build 1.7.0_51-b13)
Java HotSpot(TM) Client VM (build 24.51-b03, mixed mode)
I tried restaring both shells, in case there was some environment change that one hadn't picked up, but that didn't solve the problem. Also, cmd.exe behaves the same as powershell. Does anyone know why running the exact same executable in cygwin vs powershell would end up running different JVMs?
Is Cygwin a 32-bit app? It's possible that, if Cygwin is 32-bit, the operating system is redirecting c:\windows\system32 (the real, 64-bit System32 folder) to c:\windows\syswow64 (the 32-bit System32 folder).
Compare java.exe in c:\windows\system32 to java.exe in c:\windows\syswow64. They might be different.
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")