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

Michael Hall mik3hall at
Mon Feb 20 15:39:37 PST 2012

On Feb 20, 2012, at 11:31 AM, Mike Swingler wrote:

> The name of the directory is less important, as long as it accurately conveys the content of what is inside. All of the contents of the directory are hauled onto the classpath, perhaps "ClassPath" makes sense, if there is no intention to manually specify the classpath with app-reletive paths from the Info.plist.

After browsing through these this is the one that I'd still sort of like to be sure I'm clear on and think might be a concern to others.

It seems like the ability of the developer to control classpath to any extent is being limited for some reason.
There is no longer a Java plist dictionary key for classpath is a correct understanding?
They can only place their files and resources in predetermined locations and then the launcher code will automatically build the classpath from what's there.
Is this a code signing issue or why are these former features being eliminated or restricted? 
(OK, include $APP_PACKAGE in that as well. Why is it no longer available? Is there a reason to get rid of these things? It did provide the only way I currently know of to plist reference into the embedded jre/jdk bundle, which someone, sometime might find useful).

More information about the macosx-port-dev mailing list