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

Michael Hall mik3hall at gmail.com
Sat Feb 18 08:17:35 PST 2012

[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 $JAVALIBRARYPATH or similar that would allow this to specify a path within the 'code signed bundle'? You should be able to specify -Djava.library.path=$JAVAROOT 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.

More information about the macosx-port-dev mailing list