Problem:
After installing Java SE version 14.0.1 I tried to run the command java in CMD because I wanted to check if everything works as it should, but an error occurred because CMD could not find what I wanted.
I checked the system environment variable to see if the path for the Java JDK was set, but no, it was not set.
Question:
Why was the path not set by the Java JDK after installing Java SE 14.0.1?
It depens on the installator provider by the combianation of vendor and version. As far as I know the AdoptOpenJDK add the PATH variable
I have recently uninstalled JDK 11 and installed JDK 8. For confirmation, I want to check which JDK is installed on my Windows 10 machine. I typed java -version on cmd then get the error message
java is not recognized as an internal or external command
How to know which JDK version installed on my PC?
you might need to add path in environment variables which you can find in Control Panel
open the Jdk where you installed and add until /bin in the path in environment variables.
Add until /bin in path variable in System Variables which is residing in Environment Variables.
Then do
java -version
which might show up.
If still problem persists, try restarting your pc and see.
You need to update your Windows path to include your %JAVA_HOME%\bin directory. %JAVA_HOME% is the directory that you installed Java into and is also an environment variable that you need to configure for command line execution of your applications. You can edit both of these in the Windows control panel and you should restart.
When you run java -version you will see the internal version number. This is explained here: https://en.wikipedia.org/wiki/Java_version_history.
Basically, you can ignore the 1. when reading version number. The _xxx is a reference to the most recent patch or build release.
On Windows 10, this required mapping the environment variable for JAVA_HOME to the JDK installation directory. Use these steps:
Run the installer for the JDK. (available for windows here: https://www.oracle.com/java/technologies/downloads/#jdk17-windows)
windows key -> Environment Variables, select the only result
In the System Properties window that opened, select Environment Variables
Select new button under the User variables section
Variable name: JAVA_HOME, Variable Value: <The JDK filepath from step 0>
ok all open menus
Close any open cmd prompt windows
open a new cmd window and type echo %JAVA_HOME% It should print the installation path for the JDK.
To get your jdk location in Windows, run this at a command prompt:
where java
This lists any and all locations of java.exe, including from your JAVA_HOME. For example, the 3rd line here reflects my JAVA_HOME location, where I'm pointing to JDK 8:
C:\Users\me> where java
C:\Program Files\Common Files\Oracle\Java\javapath\java.exe
C:\Program Files (x86)\Common Files\Oracle\Java\javapath\java.exe
C:\Program Files\Java\jdk1.8.0_202\bin\java.exe
Note for comparison that java -version does not reflect my JAVA_HOME location and in fact shows java version 11 instead of 8:
C:\Users\me> java -version
java version "11.0.15" 2022-04-19 LTS
Java(TM) SE Runtime Environment 18.9 (build 11.0.15+8-LTS-149)
Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.15+8-LTS-149, mixed mode)
This is confusing because my Java compiles (e.g., via mvn) use JDK 8 since that's what my JAVA_HOME is pointing to. (I'm not even sure where the version 11 it found came from; possibly from when I installed maven.)
Determining the difference between the JRE and JDK you're running has never been straightforward. Seems like java -version used to be a way to do this, but no longer.
Adding to the complexity, you can also supposedly get your Java version info from Control Panel > Programs > Java > About. For me, that shows Version 8. That's despite java -version showing version 11.0.15. And it doesn't change even if I point my JAVA_HOME to JDK 11.
Note that this answer is also helpful. In my case, that helped me determine that I have java.exe and javac.exe at C:\Program Files (x86)\Common Files\Oracle\Java\javapath and C:\Program Files\Common Files\Oracle\Java\javapath. Depending on which one I have listed first in my Path variable, I get different results when i run java -version or java --version. The former seems to work when Java 8 is listed first; the latter when Java 11 is first.
I want to start my tomcat with a different java version than the "standard one". On my server java 6 is installed (java -version returns: java version "1.6.0_34")
I also downloaded a java 7 jdk and put it to /opt/oracle/7/jdk1.7.0_55/ and wanted my tomcat to run with java 7. So I added export JAVA_HOME=/opt/oracle/7/jdk1.7.0_55 to my script /etc/init.d/tomcat7.
When I try to start my tomcat via sudo /etc/init.d/tomcat7 start I get /opt/tomcat7/bin/catalina.sh: 1: eval: /opt/oracle/7/jdk1.7.0_55/bin/java: not found
But when I type ll /opt/oracle/7/jdk1.7.0_55/bin I get -rwxr-xr-x 1 root root java* So the path should be correct!?
I can't figure out why it doesn't work. Any hints appreciated. :-)
EDIT:
I probably just downloaded the wrong jdk (32 bit instead of 64)
You probably downloaded the wrong JDK. From your comments, it seems to be a 32bit JDK. If you have a 64bit Linux, then you can't load the executables.
uname -m tells you the architecture of your system. It should be i686 or i586 but probably is x86_64.
(Wasn't sure if this should go on SU... migration is certainly an option, but more programmers read questions here, so here goes).
I am running Mac OS X 10.8.4, and I have Apple's JDK 1.6.0_51 installed as well as Oracle's JDK 1.7.0_25. I recently installed Oracle's 1.8 preview JDK for some pre-release software that requires it. Now, when I run /usr/libexec/java_home, I get this:
$ /usr/libexec/java_home -V
Matching Java Virtual Machines (4):
1.8.0, x86_64: "Java SE 8" /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home
1.7.0_25, x86_64: "Java SE 7" /Library/Java/JavaVirtualMachines/jdk1.7.0_25.jdk/Contents/Home
1.6.0_51-b11-457, x86_64: "Java SE 6" /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home
1.6.0_51-b11-457, i386: "Java SE 6" /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home
Great.
However, running:
$ java -version
Returns:
java version "1.8.0-ea"
That means that the default version of Java is currently the pre-release version, which breaks some "normal" packages (in my case, VisualVM).
I can't set JAVA_HOME because launching applications ignores environment variables, even when launching from the command line (e.g. $ open /Applications/VisualVM.app).
So, is there a file I can edit where I can set my JVM ordering preferences globally?
(Please don't tell me to launch the Java Preferences Panel because that simply does not work: it does not contain anything useful and only lists one of the 4 JVMs that I have installed.)
Update:
Oracle JVMs live in /Library/Java/JavaVirtualMachines. Re-naming the JDK 1.8 directory to jdk1.8.0.jvm.xyz does not change anything: java_home still finds it in the right place, and running /usr/bin/java still executes the 1.8 JVM. This is not an issue with synlinks, etc.
Answers to Similar Questions
While this answer offers what amounts to a hack that will remove versions of Java from being picked up by java_home, it still does not answer this question of how java_home chooses its default and whether or not users can non-destructively set it.
I think JAVA_HOME is the best you can do. The command-line tools like java and javac will respect that environment variable, you can use /usr/libexec/java_home -v '1.7*' to give you a suitable value to put into JAVA_HOME in order to make command line tools use Java 7.
export JAVA_HOME="`/usr/libexec/java_home -v '1.7*'`"
But standard double-clickable application bundles don't use JDKs installed under /Library/Java at all. Old-style .app bundles using Apple's JavaApplicationStub will use Apple Java 6 from /System/Library/Frameworks, and new-style ones built with AppBundler without a bundled JRE will use the "public" JRE in /Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home - that's hard-coded in the stub code and can't be changed, and you can't have two different public JREs installed at the same time.
Edit: I've had a look at VisualVM specifically, assuming you're using the "application bundle" version from the download page, and this particular app is not an AppBundler application, instead its main executable is a shell script that calls a number of other shell scripts and reads various configuration files. It defaults to picking the newest JDK from /Library/Java as long as that is 7u10 or later, or uses Java 6 if your Java 7 installation is update 9 or earlier. But unravelling the logic in the shell scripts it looks to me like you can specify a particular JDK using a configuration file.
Create a text file ~/Library/Application Support/VisualVM/1.3.6/etc/visualvm.conf (replace 1.3.6 with whatever version of VisualVM you're using) containing the line
visualvm_jdkhome="`/usr/libexec/java_home -v '1.7*'`"
and this will force it to choose Java 7 instead of 8.
I've been there too and searched everywhere how /usr/libexec/java_home works but I couldn't find any information on how it determines the available Java Virtual Machines it lists.
I've experimented a bit and I think it simply executes a ls /Library/Java/JavaVirtualMachines and then inspects the ./<version>/Contents/Info.plist of all runtimes it finds there.
It then sorts them descending by the key JVMVersion contained in the Info.plist and by default it uses the first entry as its default JVM.
I think the only thing we might do is to change the plist: sudo vi /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Info.plist and then modify the JVMVersion from 1.8.0 to something else that makes it sort it to the bottom instead of the top, like !1.8.0.
Something like:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
...
<dict>
...
<key>JVMVersion</key>
<string>!1.8.0</string> <!-- changed from '1.8.0' to '!1.8.0' -->`
and then it magically disappears from the top of the list:
/usr/libexec/java_home -verbose
Matching Java Virtual Machines (3):
1.7.0_45, x86_64: "Java SE 7" /Library/Java/JavaVirtualMachines/jdk1.7.0_45.jdk/Contents/Home
1.7.0_09, x86_64: "Java SE 7" /Library/Java/JavaVirtualMachines/jdk1.7.0_09.jdk/Contents/Home
!1.8.0, x86_64: "Java SE 8" /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home
Now you will need to logout/login and then:
java -version
java version "1.7.0_45"
:-)
Of course I have no idea if something else breaks now or if the 1.8.0-ea version of java still works correctly.
You probably should not do any of this but instead simply deinstall 1.8.0.
However so far this has worked for me.
I actually looked at this a little in the disassembler, since source isn't available.
/usr/bin/java and /usr/libexec/java_home both make use of JavaLaunching.framework. The JAVA_HOME environment variable is indeed checked first by /usr/bin/java and friends (but not /usr/libexec/java_home.) The framework uses the JAVA_VERSION and JAVA_ARCH envirionment variables to filter the available JVMs. So, by default:
$ /usr/libexec/java_home -V
Matching Java Virtual Machines (2):
11.0.5, x86_64: "Amazon Corretto 11" /Library/Java/JavaVirtualMachines/amazon-corretto-11.jdk/Contents/Home
1.8.0_232, x86_64: "Amazon Corretto 8" /Library/Java/JavaVirtualMachines/amazon-corretto-8.jdk/Contents/Home
/Library/Java/JavaVirtualMachines/amazon-corretto-11.jdk/Contents/Home
But setting, say, JAVA_VERSION can override the default:
$ JAVA_VERSION=1.8 /usr/libexec/java_home
/Library/Java/JavaVirtualMachines/amazon-corretto-8.jdk/Contents/Home
You can also set JAVA_LAUNCHER_VERBOSE=1 to see some additional debug logging as far as search paths, found JVMs, etc., with both /usr/bin/java and /usr/libexec/java_home.
In the past, JavaLaunching.framework actually used the preferences system (under the com.apple.java.JavaPreferences domain) to set the preferred JVM order, allowing the default JVM to be set with PlistBuddy - but as best as I can tell, that code has been removed in recent versions of macOS. Environment variables seem to be the only way (aside from editing the Info.plist in the JDK bundles themselves.)
Setting default environment variables can of course be done through your .profile or via launchd, if you need them be set at a session level.
It's actually pretty easy.
Let's say we have this in our JavaVirtualMachines folder:
jdk1.7.0_51.jdk
jdk1.8.0.jdk
Imagine that 1.8 is our default, then we just add a new folder (for example 'old') and move the default jdk folder to that new folder.
Do java -version again et voila, 1.7!
I tested "jenv" and other things like setting "JAVA_HOME" without success.
Now I ended up with following solution:
function setJava {
export JAVA_HOME="$(/usr/libexec/java_home -v $1)"
launchctl setenv JAVA_HOME $JAVA_HOME
sudo ln -nsf "$(dirname ${JAVA_HOME})/MacOS" /Library/Java/MacOS
java -version
}
(added to ~/.bashrc or ~/.bash.profile or ~/.zshrc)
And calling like that:
setJava 1.8
java_home will handle the wrong input. So you can't do something wrong.
Maven and other stuff will pick up the right version now.
It's pretty simple, if you don't mind rolling up your sleeves... /Library/Java/Home is the default for JAVA_HOME, and it's just a link that points to one of:
/System/Library/Java/JavaVirtualMachines/1.?.?.jdk/Contents/Home
/Library/Java/JavaVirtualMachines/jdk1.?.?_??.jdk/Contents/Home
So I wanted to change my default JVM/JDK version without changing the contents of JAVA_HOME... /Library/Java/Home is the standard location for the current JVM/JDK and that's what I wanted to preserve... it seems to me to be the easiest way to change things with the least side effects.
It's actually really simple. In order to change which version of java you see with java -version, all you have to do is some version of this:
cd /Library/Java
sudo rm Home
sudo ln -s /Library/Java/JavaVirtualMachines/jdk1.8.0_60.jdk/Contents/Home ./Home
I haven't taken the time but a very simple shell script that makes use of /usr/libexec/java_home and ln to repoint the above symlink should be stupid easy to create...
Once you've changed where /Library/Java/Home is pointed... you get the correct result:
cerebro:~ magneto$ java -version
java version "1.8.0_60"
Java(TM) SE Runtime Environment (build 1.8.0_60-b27) Java HotSpot(TM)
64-Bit Server VM (build 25.60-b23, mixed mode)
Oracle's uninstallation instructions for Java 7 worked for me.
Excerpt:
Uninstalling the JDK
To uninstall the JDK, you must have Administrator privileges and execute the remove command either as root or by using the sudo(8) tool.
Navigate to /Library/Java/JavaVirtualMachines and remove the directory whose name matches the following format:*
/Library/Java/JavaVirtualMachines/jdk<major>.<minor>.<macro[_update]>.jdk
For example, to uninstall 7u6:
% rm -rf jdk1.7.0_06.jdk
A bit late but as this is an ongoing issue with Mac OSX...
The simplest solution I found was to simply remove the OpenJDK stuff that Apple installs. Every time an update of Mac OSX arrives it gets installed and you'll need to remove it again.
This works really well if you develop apps for Google App Engine on your mac using Java. The OpenJDK does not work well and the Java version that comes with the Mac OSX Yosemite upgrade will make the Eclipse Plug-in for App Engine crash on every deployment with the helpful error: "Read timed out".
Edit: this information is for visualvm specifically, not for any other java app
As mentioned by others, you need to modify the visualvm.conf
For the latest version of JvisualVM 1.3.6 on Mac, the install directories have changed.
It is currently in
/Applications/VisualVM.app/Contents/Resources/visualvm/etc/visualvm.conf.
However this may depend on where you have installed VisualVM. The easiest way to find where your VisualVM is to start it, and then look at the process using:
ps -ef | grep VisualVM
You will see something like:
... -Dnetbeans.dirs=/Applications/VisualVM.app/Contents/Resources/visualvm/visualvm...
You want to take the netbeans.dir property and look up a directory and you will find the etc folder.
Uncomment this line in the visualvm.conf and change the path to the jdk
visualvm_jdkhome="/path/to/jdk"
Additionally, if you are having slowness with your visualvm and you have a lot of memory, I would suggest greatly increasing the amount of memory available and running it in server mode:
visualvm_default_options="-J-XX:MaxPermSize=96m -J-Xmx2048m -J-Xms2048m -J-server -J-XX:+UseCompressedOops -J-XX:+UseConcMarkSweepGC -J-XX:+UseParNewGC -J-XX:NewRatio=2 -J-Dnetbeans.accept_license_class=com.sun.tools.visualvm.modules.startup.AcceptLicense -J-Dsun.jvmstat.perdata.syncWaitMs=10000 -J-Dsun.java2d.noddraw=true -J-Dsun.java2d.d3d=false"
Simplify the need :-)
Steps to changes --
Find the installed version on your machine by executing following command
/usr/libexec/java_home -V
then you might see like below if there are multiple version of JDK installed
11.0.16 (arm64) "Homebrew" - "OpenJDK 11.0.16" /opt/homebrew/Cellar/blabla
1.8.0_292 (x86_64) "AdoptOpenJDK" - "AdoptOpenJDK 8" /Library/Java/JavaVirtualMachines/bala
Create Env file based your machine, for mac like below create or edit the your system Environment file either .zshenv, .zshprofile etc...
nano ~/.zshenv
export JAVA_HOME=$(/usr/libexec/java_home -v 1.8.0_292)
Then the magic is done, where ever this symlink used all those java refer to version which you set! Happy coding Boys & Girls.
I had a similar situation, and the following process worked for me:
In the terminal, type
vi ~/.profile
Then add this line in the file, and save
export JAVA_HOME=/Library/Java/JavaVirtualMachines/jdk<version>.jdk/Contents/Home
where version is the one on your computer, such as 1.7.0_25
Exit the editor, then type the following command make it become effective
source ~/.profile
Then type java -version to check the result
java -version
What is .profile?
From:http://computers.tutsplus.com/tutorials/speed-up-your-terminal-workflow-with-command-aliases-and-profile--mac-30515
.profile file is a hidden file. It is an optional file which tells the system which commands to run when the user whose profile file it is logs in. For example, if my username is bruno and there is a .profile file in /Users/bruno/, all of its contents will be executed during the log-in procedure.
MacOS uses /usr/libexec/java_home to find the current Java Version. One way to bypass is to change the plist file as explained by #void256 above.
Other ways is to take the backup of the java_home and replace it with your own script java_home having the code
echo $JAVA_HOME
Now export the JAVA_HOME to the desired version of the SDK by adding the following commands to the ~/.bash_profile.
export JAVA_HOME="/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home"
launchctl setenv JAVA_HOME $JAVA_HOME /// Make the environment variable global
Run the command source ~/.bash_profile to the run the above commands.
Anytime one needs to change the JAVA_HOME he can reset the JAVA_HOME value in the ~/.bash_profile file.
I wanted to change default java version form 1.6* to 1.7*. I tried the following steps and it worked for me:
Removed link "java" from under /usr/bin
Created it again, pointing to the new location:
ln -s /Library/Java/JavaVirtualMachines/jdk1.7.0_51.jdk/Contents/Home/bin/java java
verified with "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)
I installed the latest JDK 1.6.0_25 on my Windows 7 64-bit machine. I then tried "java -version" on the command prompt, without editing the path variable. It worked, so I assumed that the installation added the new path to the environment.
But when I looked at the path variable through the Advanced System Settings tab, there was no sign of "C:\Program Files (x86)\Java\jdk1.6.0_25\bin\" or anything equivalent to it.
How is the path getting resolved?
If you're on Windows Server 2003, Vista, or Windows 7, you can try the where command:
C:\>where java
For anyone using Linux, the where equivalent is whereis.
it is kept in the registry: HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment
Java install a small exe in the system folder that looks up the keep and redirects there, so no PATH necessary.
Linux version usually uses update-alternatives (depends on the distribution, of course)