Thomas Much's Weblog

Mon, Jan 23, 2006

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:

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.