Thomas Much's Weblog

JavaApplicationStub

Java applications can be launched like native Mac OS X applications if their bytecode (usually a JAR archive) is packaged as a Mac OS X application bundle. The actual launch code is a native executable, usually called JavaApplicationStub, that's placed in Your.app/Contents/MacOS/ (if you want to use a different name for the stub file, you'll have to change the value of the CFBundleExecutable key in Info.plist, too).

The stub file changed from Java release to Java release, and unfortunately some stub versions have been more capable of launching Java applications on various system versions than others. Just recently, after updating to QuickTime 7.0.4 on Mac OS X 10.3.9, certain old stub files refused to launch Java applications any more (the fix is easy: just copy a current stub file from /System/Library/Frameworks/JavaVM.framework/Resources/MacOS/ to your affected application bundles).

These problems led to a discussion on Apple's Java developer mailing list on how to ensure that always the latest stub version is used. We came up with the following solution: Don't use a copy of the stub file in your application bundle, but a symlink (not a Finder alias!) to the system's current stub instead:

ln -s /System/Library/Frameworks/JavaVM.framework/Resources/MacOS/JavaApplicationStub PathToYour.app/Contents/MacOS/JavaApplicationStub

The solution has a little drawback: You cannot use a different name than JavaApplicationStub, which makes it hard to tell different Java processes apart in a Unix shell (the Finder uses the bundle name from Info.plist, which can still be whatever you want, so this seems acceptable in most cases). And of course, the symlink will break if Apple decides to change the framework structure some time. But until now, the framework structure has proven to be more stable than a copy of the stub file itself, so the symlink is likely the most elegant solution to always use the latest stub in your Java application bundles.

[Update] There have been reports that this approach does not work as expected - you cannot use more than one Java application that uses the linked stub at the same time... So it seems we'll have to wait for Apple to provide a reliable solution.