macos - Understanding Oracle's Java on Mac

Question

I've been using Java on OS X for many, many years and recently when Apple stopped including Java by default I let the OS go and install it for me (Apple's variety, of course).

So now I'm using OS X 10.8 and I need to install Java 7 so I just got Oracle's Update 15 in DMG form and ran the installer. It updated my /usr/bin/java (and related files) to point here:

/System/Library/Frameworks/JavaVM.framework/Versions/Current/Commands/java

Tracing this back to '/System/Library/Frameworks/JavaVM.framework/Versions' everything either points to 'Current' or 'CurrentJDK', the former being a link to 'A' (which is Oracle's Java 7, from what I can tell, not sure why it is 'A') and the latter being a link to Apple's Java 6 in '/System/Library/Java/JavaVirtualMachines/1.6.0.jdk'.

Now this is all really confusing but this isn't even my question yet. It appears there is a Java 7 installed here:

/System/Library/Frameworks/JavaVM.framework/Versions/A

But there is also a Java 7 installed here:

/Library/Java/JavaVirtualMachines/jdk1.7.0_15.jdk

Finding 'java' in both and printing out the version yields the same version and build (java version "1.7.0_15"), however, when hashing the files they are different.

So does this mean Oracle installed Java 7 in two different places? If so, why? Which am I supposed to use? And why do some things still point to Java 6 (CurrentJDK).

I've looked on Oracle's website but nothing there clears anything up.

Answer 1

Oracle's JVM is only installed in one location. You've been misled!

As you've noted, the Java commands in /usr/bin are symlinks to binaries in /System/Library/Frameworks/JavaVM.framework/Versions/Current/Commands. The binaries within that directory are stub applications that determine which Java VM to use*, and then exec the corresponding real binary within that VM version. This is why all of the binaries within /System/Library/Frameworks/JavaVM.framework/Versions/Current/Commands are almost identical in size, despite the fact that you'd expect them to be implementing quite different functionality.

You can see this in action by using dtrace:

mrowe@angara:~$ sudo dtrace -n 'syscall::posix_spawn:entry { trace(copyinstr(arg1)); }' -c "/usr/bin/java -version"
dtrace: description 'syscall::posix_spawn:entry ' matched 1 probe
dtrace: pid 44727 has exited
CPU     ID                    FUNCTION:NAME
  8    619                posix_spawn:entry   /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home/bin/java

The given dtrace invocation prints out the path argument to posix_spawn when it is called by java -version. In my case the stub application has found Apple's Java 1.6 runtime in /System/Library/Java/JavaVirtualMachines/1.6.0.jdk and is invoking that version of the java command.

The stub binaries also have another benefit: when they detect that no Java VM is installed they will prompt the user to install one.

As for the CurrentJDK symlink, as best as I can tell this for sake of backwards-compatibility with the past when Apple was the only source of the JVM on OS X.

---

* A combination of factors are considered when determining which Java VM should be used. JAVA_HOME is used if set (try JAVA_HOME=/tmp java). If JAVA_HOME is not set then the list of all virtual machines on the system is discovered. The JAVA_VERSION and JAVA_ARCH environment variables are used, if set, to filter the list of virtual machines to a particular version and supported architecture. The resulting list is then sorted by architecture (preferring 64-bit over 32-bit) and version (newer is better), and the best match is returned.