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

Scott Palmer swpalmer at
Wed Feb 22 06:01:11 PST 2012

On 2012-02-22, at 8:27 AM, Greg Brown wrote:

>>>> -Djava.class.path might be a workaround to get too tools.jar. 
>>>> It would also be a workaround to point to any file anywhere on the machine wouldn't it?
>>> That is a very bad workaround. If you need a tools.jar, it should ship in your bundle.
> I agree 100%. And since it is already included in the JDK, it seems silly to require users to copy it to the Java directory.
>> I think Greg had mentioned the possibility of changing the starting directory so you could relative path into the bundled jre.
> Right. I was thinking that we could have the launcher app set the working directory to the bundle root at startup. Then you could add this to the build script to add tools.jar (or anything else within the bundle) to the class path:
> <option value="-classpath Contents/PlugIns/1.7.0.jdk/Contents/Home/lib/tools.jar"/>
> G

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.  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.

Just a thinking out loud.

Scott P.

More information about the macosx-port-dev mailing list