How can I change the default Mac OS Java VM returned from / usr / libexec / java_home

Question

(I wasn’t sure if it was worth doing with SU ... migration is definitely an option, but more programmers read questions here, so here).

I am using Mac OS X 10.8.4 and I have installed Apple JDK 1.6.0_51 and Oracle JDK 1.7.0_25. I recently installed the Oracle 1.8 Preview JDK for some preview version of the software that requires this. 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 

Fine.

However, it works:

 $ java -version 

Returns:

 java version "1.8.0-ea" 

This means that the default Java version is currently a preview version that breaks some “normal” packages (in my case, VisualVM).

I cannot set JAVA_HOME because when I launch applications, environment variables are ignored, even when launched from the command line (for example, $ open/Applications/VisualVM.app ).

So, is there a file that I can edit where I can set my JVM ordering preferences globally?

(Please do not tell me to launch the Java settings panel because it simply does not work: it does not contain anything useful and contains only one of the 4 JVMs that I installed.)

Update :

Oracle JVMs live in /Library/Java/JavaVirtualMachines . jdk1.8.0.jvm.xyz the JDK 1.8 directory in jdk1.8.0.jvm.xyz does not change anything: java_home still finds it in the right place, and running / usr / bin / java still runs the 1.8 JVM. This is not a problem with links, etc.

Answers to similar questions

Although this answer suggests what constitutes a hack that will remove Java versions from choosing java_home, it still does not answer the question of how java_home chooses the default value and whether users can set it non-destructively .

Answer 1

I think JAVA_HOME is the best you can do. Command line tools like java and javac will respect this environment variable, you can use /usr/libexec/java_home -v '1.7*' to give you a suitable input value in JAVA_HOME to force the command line tools to use Java 7 .

 export JAVA_HOME="`/usr/libexec/java_home -v '1.7*'`" 

But standard double-click batch applications do not use the JDKs installed under /Library/Java at all. Old-style .app using Apple JavaApplicationStub will use Apple Java 6 from /System/Library/Frameworks , and newer ones in AppBundler style without an associated JRE will use the "public" JRE in /Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home , which is hardcoded in the stub code and cannot be changed, and you cannot install two different public JREs at the same time.

---

Edit: I looked at VisualVM specifically, assuming that you are using the "application bundle" version from the download page , and this particular application 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. By default, it selects a new JDK from /Library/Java if it is 7u10 or newer, or uses Java 6 if your Java 7 installation is updated 9 or earlier. But unraveling the logic in shell scripts, it looks like you can specify a specific JDK using a configuration file.

Create a text file ~/Library/Application Support/VisualVM/1.3.6/etc/visualvm.conf (replace 1.3.6 with any version of VisualVM that you are using) containing the line

 visualvm_jdkhome="`/usr/libexec/java_home -v '1.7*'`" 

and this will make him choose Java 7 instead of 8.

Answer 2

I was there too and searched everywhere where /usr/libexec/java_home , but I could not find any information on how it determines the available Java virtual machines that it lists.

I experimented a bit and I think that it just executes ls /Library/Java/JavaVirtualMachines and then checks ./<version>/Contents/Info.plist all the ./<version>/Contents/Info.plist found there.

Then it sorts them in descending order using the JVMVersion key contained in Info.plist, and by default it uses the first record as its default JVM.

I think the only thing we can do is change plist: sudo vi /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Info.plist and then change the JVMVersion from 1.8.0 to something else. which makes it sorted below and not above, for example !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 need to logout / login, and then:

 java -version java version "1.7.0_45" 

:-)

Of course, I have no idea that now something will break or the version of java version 1.8.0-ea is working correctly.

You probably shouldn't do this, but instead, just uninstall 1.8.0.

However, so far this has worked for me.

Answer 3

Oracle uninstall instructions for Java 7 helped me.

Exposure:

Removing the JDK To remove the JDK, you must have administrator rights and execute the delete command as root or using the sudo (8) tool.

Go to / Library / Java / JavaVirtualMachines and delete the directory whose name corresponds to the following format: *

/Library/Java/JavaVirtualMachines/jdk<major>.<minor>.<macro[_update]>.jdk

For example, to remove 7u6:

% rm -rf jdk1.7.0_06.jdk

Answer 4

This is actually pretty easy. Say we have this in our JavaVirtualMachines folder:

• jdk1.7.0_51.jdk
• jdk1.8.0.jdk

Imagine 1.8 is our default, we just add a new folder (for example, "old") and move the default jdk folder to this new folder. Do java -version again et voila, 1.7!

Answer 5

It's pretty simple if you don't mind unwinding the sleeves ... / Library / Java / Home by default for JAVA_HOME, and it's just a link that points to one of the following:

• / 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 what I wanted to save ... it seems to me that this the easiest way to change the situation with the least side effects.

It is really easy. To change the 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 did not find the time, but a very simple shell script that uses / usr / libexec / java _home, and ln to repeat the specified symbolic link should be silly easy to create ...

After you change where / Library / Java / Home is listed, 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) 

Answer 6

A bit late, but since this is a problem with Mac OSX ...

The simplest solution I have found is to simply remove the OpenJDK stuff that Apple installs. Every time a Mac OSX update arrives, it installs and you will need to uninstall it again.

This works very well if you are developing applications for Google App Engine on your Mac using Java. OpenJDK does not work, and the version of Java that comes with the Mac OSX Yosemite update will force the Eclipse plug-in for App Engine disaster recovery for every deployment with a useful error: "Read timed."

Answer 7

I checked "jenv" and other things like setting "JAVA_HOME", but to no avail. Now I agree with the 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 this:

 setJava 1.8 

java_home will handle invalid input. so you cannot do something wrong. Maven and other things will now pick the right version.

Answer 8

MacOS uses / usr / libexec / java _home to find the current version of Java. One way around this is to modify the plist file as described in @ void256 above. Other ways is to backup java_home and replace it with your own java_home script that has code
echo $ JAVA_HOME

Now export JAVA_HOME to the desired version of the SDK by adding the following commands to the ~ / .bash_profile file. 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 source of the ~ / .bash_profile command to run the specified commands.

At any time when you need to change JAVA_HOME, it can reset the JAVA_HOME value in the ~ / .bash_profile file.

Answer 9

Edit: this information is for visualvm specifically, not for any other java application

As others have already mentioned, you need to modify visualvm.conf

For the latest version of JvisualVM 1.3.6 on Mac, installation directories have changed.

Currently /Applications/VisualVM.app/Contents/Resources/visualvm/etc/visualvm.conf .

However, this may depend on where you installed VisualVM. The easiest way to find where your VisualVM is to run it and then look at the process using:

ps -ef | grep VisualVM

You will see something like:

... -Dnetbeans.dirs = / Applications / VisualVM.app / Content / Resources / visualvm / visualvm ...

You want to take the netbeans.dir property and find the directory, and you will find the folder etc.

Uncomment this line in visualvm.conf and change the jdk path

 visualvm_jdkhome="/path/to/jdk" 

In addition, if you have slowness with your visualvm and you have a lot of memory, I would suggest significantly increasing the amount of available memory 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" 

Answer 10

I had a similar situation and the following process worked for me:

• In the terminal, enter

   vi ~/.profile 

• Then add this line to the file and save

   export JAVA_HOME=/Library/Java/JavaVirtualMachines/jdk<version>.jdk/Contents/Home 

  where version is the version of your computer, for example 1.7.0_25

• Exit the editor, then enter the following command to make it effective.

   source ~/.profile 

Then enter java -version to check the result

  java -version 

What is the .profile? From: http://computers.tutsplus.com/tutorials/speed-up-your-terminal-workflow-with-command-aliases-and-profile--mac-30515

File

.profile is a hidden file. This is an optional file that tells the system which commands to run when the user whose profile file is in it. For example, if my username is bruno, and the / Users / bruno / file contains the entire .profile file, all its contents will be executed during the login procedure.

Answer 11

I wanted to change the java version of the default version 1.6 * to 1.7 *. I tried the following steps and it worked for me:

• Removed "java" link from / usr / bin
• Created it again, pointing to a new location:

ln -s / Library / Java / JavaVirtualMachines / jdk1.7.0_51.jdk / Contents / Home / bin / java java

• checked using "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)