Selecting Java Version – Part 2
In the previous post I showed how to configure and access the various Java versions installed on Leopard. In this post I want to dig a little deeper into what is going on behind the scenes as it relates to working with Java on Mac OS X. None of what I describe here will speed up your development process, however, it may save you some time if/when the day comes that something is amiss when working with Java.
Let’s begin by looking at the setting for JAVA_HOME on my system:
All works well, despite the fact that this technical article on Apple specifies that JAVA_HOME should point to:
So what’s up with that? Having a closer look at the file system will reveal what’s going on. The figure below shows a directory listing of the path /Library/Java/Home:
It’s all about symbolic links, so effectively the path Apple recommends, is a link to the path that I have set as my JAVA_HOME. If you look at the listing below you’ll notice that /System/Library/Framework/JavaVM.framework/Home is a link to /System/Library/Framework/JavaVM.framework/Versions/CurrentJDK/Home.
I think you can guess where I’m going with this next. If we look one level deeper, we’ll see that the reference to /CurrentJDK/Home includes a /bin directory, which is where all the Java executables (see below):
The listing below shows the contents of the /bin again, a list of links:
Okay, we’ve got to be nearing the end here…if we list the files that are located at ../../Commands we will finally see the executables, no more links:
What do all the links accomplish versus a simply directory and path structure? In a word, flexibility. Using links, one can change the reference to the /CurrentJDK directory and in one fell swoop, change which executables files (that is, which version of Java is used). Thus, when a new version of Java is downloaded and installed via the Mac OS X Software Update, or you upgrade to a new version of Mac OS X, getting the latest version of Java is nothing more than changing the appropriate symbolic links.
The good news is that unless you manually upgrade Java, all the work happens for you with no effort on your part. However, my intention in jumping through all these hoops is to show you how the linking process works, so if/when the day comes that you need to figure out why the “wrong” Java version is compiling or packaging your code, you have a path (no pun intended) to make some sense of where the “active” Java executables live.