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

[Michael Hall]

[Limiting response to macosx-port]

On Feb 17, 2012, at 7:02 PM, Mike Swingler wrote:

> On Feb 17, 2012, at 4:47 PM, Michael Hall wrote:
> 
>> On Feb 17, 2012, at 6:36 PM, Mike Swingler wrote:
>> 
>>> Apps from the Mac App Store can load additional libraries, however I think it is only prudent for them to restrict their loading to libraries within their own code signed bundle.
>> 
>> OK, sort of wondered about that. I would maybe see an advantage to loading from classpath in this case. Or, will the plist support some sort of $JAVA_LIBRARY_PATH or similar that would allow this to specify a path within the 'code signed bundle'?
> 
> You should be able to specify -Djava.library.path=$JAVA_ROOT in the VM arguments Info.plist key to refer to the (YourApp.app)/Contents/Java directory.
> 

Actually, it looks to be there already. In the JavaAppLauncher JVMArgs.m off the changeset(?) mentioned by Greg Brown.

   // add $JAVAROOT directory to the JNI library search path
    setenv("JAVA_LIBRARY_PATH", [javaRoot UTF8String], 1);

Haven't got my app launching yet to verify that yet. So far it doesn't seem to honor the ClassPath plist key which from a quick look at the source it seems like it should. Could be something I'm doing wrong yet there though. Just trying to take Greg Browns SwingSet2 demo and tweak it manually at this point. Haven't tried the ant build, figure thats step 2. 

OK, I think there may be a problem in that the bundle directory has been changed to JavaVM
but JVMArgs.m shows in one place
NSString *GetJavaRoot(NSDictionary *jvmInfoDict) {
    NSObject *javaRoot = [jvmInfoDict objectForKey:@"$JAVAROOT"];
    if (![javaRoot isKindOfClass:[NSString class]]) return @"$APP_PACKAGE/Contents/Java";
    return (NSString *)javaRoot;
}
I can access the XCode project now but get errors on the build, so can't verify if changing the /Java to /JavaVM would correct $JAVAROOT issues.