The gist of the application is to instruct iTunes to play a random song, move to the next song, pause, etc. I’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’s needed to write an intriguing (and hopefully useful) application.

Technorati Tags: AppleScript, Cocoa, Java, netbeans, screencast

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’ll show a more comprehensive (read: interesting) example where it’s all about controlling iTunes using Java.

Technorati Tags: AppleScript, Cocoa, Java, netbeans, screencast

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.

Technorati Tags: Java

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.

Technorati Tags: Java