java.library.path fix for MacOS X (7145798)

Greg Brown greg.x.brown at
Wed Feb 22 06:25:52 PST 2012

> Shouldn't the working directory for a .app be consistent? If it is "/" for other application bundles, so should it be for Java application bundles.  

But any app can change its working directory at any time. It isn't required to be "/" for the life of the app.

I'm not sure that's even relevant, though. The Java app itself isn't even aware that it is running in a bundle. In fact, I think the VM may even switch the working directory to the user's home directory before the app starts. Changing the working directory to match the bundle path would be strictly for the benefit of the launcher.

> Perhaps the launcher can instead have option values that are path-aware, e.g.:
> <option value="-classpath">
> <option path="Contents/PlugIns/1.7.0.jdk/Contents/Home/lib/tools.jar">
> and prepend the path to the app bundle when encountering a relative path.

I'd really like to avoid creating "special cases" like this, if possible. The launcher has been designed to mirror, as much as possible, the process of launching a Java app from the command line. Using a relative classpath to launch a command-line app is very common, so it seems natural to support a similar convention in the launcher.


More information about the macosx-port-dev mailing list