Java

In part 1 of this series I demonstrated how to create a short Java application in NetBeans that communicated, using AppleScript, to the Mac apple event system. The application was a no thrills look into how to invoke the TextEdit application. Despite the brevity of the application it provided the foundation for this next tip, which will build on the ideas to create something a little more salient, as in, something that you might actually find yourself using.

The gist of the application is to instruct iTunes to play a random song, move to the next song, pause, etc. I” onclick=”return TrackClick(”,’javascript%3AlynkVideoPop%28719%2C’)”ll show one use of the application by wrapping the code into a bash script that allows you to invoke the program (and all commands) from within a terminal. Watch the video that follows for all the details…

This application is all of about 80 lines, including the bash script. Sometimes a little creative thinking and a few lines of code are all that” onclick=”return TrackClick(”,’javascript%3AlynkVideoPop%28719%2C’)”s needed to write an intriguing (and hopefully useful) application.


The music in the video is Led Zeppelin and the song: Moby Dick. Led Zeppelin at Amazon


A few weeks back I demonstrated how to write Ruby code inside NetBeans to control scriptable applications on a Mac, that is, communicate between Ruby and the Apple Event system. In this post, I will turn things around a bit from the previous post and use NetBeans and Java to execute AppleScript.

There is a subtle difference, in the previous post the focus was on how to write code in Ruby (inside NetBeans) using the rb-appscript bridge. This time around the approach is to work with Java and pass AppleScript code to a set of Cocoa files (classes) that will act as the bridge between our application and the Mac system.

There is one caveat – the Cocoa-Java API is deprecated as of Mac OS X Tiger. The NSAppleScript and NSMutableDictionary classes are still available, however, they are no longer on the development path within Apple. There are scripting bridges that allow you to control scriptable applications using Python, Ruby, and Objective-C. Java Native Interface (JNI) is an additional option to call platform specific code. You can read more about JNI in this technical note: JNI development on Mac OS X.

One more note, if you follow the steps in this video and the classes NSAppleScript and NSMutableDictionary are shown with lines through them (for example, NSAppleScript), this has to do with a preference setting inside NetBeans to show deprecated classes with a strike-through. You can change this as follows: From the Preferences dialog, choose Fonts/Colors; click the Syntax option; from the Language list choose Java; click on Deprecated Element; in the Effects option, choose None.

Join me in Part 2 of this tip where I” onclick=”return TrackClick(”,’javascript%3AlynkVideoPop%28719%2C’)”ll show a more comprehensive (read: interesting) example where it” onclick=”return TrackClick(”,’javascript%3AlynkVideoPop%28719%2C’)”s all about controlling iTunes using Java.


The music in the video is Led Zeppelin and the song: Moby Dick.
Click the image to see more about about Led Zeppelin and the CD (at Amazon)


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:

JAVA_HOME=/System/Library/Frameworks/JavaVM.framework/Home

All works well, despite the fact that this technical article on Apple specifies that JAVA_HOME should point to:

/Library/Java/Home

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.

Mac OS X Leopard includes multiple versions of Java in the base install. This can be quite helpful if you need to compile and run Java code across more than one version of the JDK.

You can specify which installed version of Java you prefer to use as the default by tweaking the settings within the Java Preferences application, which is located in the Utilities folder under Java. See the figure below and notice the path reference on the bottom of the figure. The full path is:/Applications/Utilities/Java/

From within the Java Preferences application, in addition to choosing the preferred Java version, there are a number of additional configuration options in the Security and Advanced tabs, with the later tab including a number of options that make it worth a visit.

One last recommendation, if you compile from the command line you can select which version of the Java compiler you are after without having to change the preferred system setting. Open ~/.bash_profile (in your home directory) and create aliases similar to the following:

alias javac-15=/System/Library/Frameworks/JavaVM.framework/Versions/1.5/Commands/java
alias javac-14=/System/Library/Frameworks/JavaVM.framework/Versions/1.4/Commands/java

Check the Java version using the above aliases as follows:

In the second part of this post I’ll show you some of the goings on behind the scenes of the Java configuration on Mac OS X.