Application classpath and tools.jar
mik3hall at gmail.com
Sun Feb 19 18:01:38 PST 2012
> At runtime, you could find tools.jar relative to the "java.home" system property. Alternately, you could file an enhancement request to the JavaAppLauncher to substitute a $JAVA_HOME variable like the original contributed implementation substituted $JAVAROOT, $APP_PACKAGE, and $USER_HOME.
OK, I think maybe the JavaAppLauncher that was included in with Greg's changeset isn't the one he's probably working with? Maybe an older version of yours(? or who evers).
The build errors I was getting were fixed when I changed the "jni.h" imports to <JavaVM/jni.h>.
I had to make quite a few other tweaks which I think just means mine wasn't really the right launcher as I said above.
Somehow I ended up with an empty classpath so I built that from scratch as...
Good enough to launch the SwingSet2 demo again anyhow.
Note that actually only the $JAVAROOT/SwingSet2.jar would of been good enough.
Note also the last. Might work for tools.jar. Still untested on my own app yet.
I will have to go back and verify a little more carefully that ClassPath key changes aren't being recognized like I thought they weren't. Although _I thought_ I printed out the java.class.path I was running with and they weren't there.
Since I'm not sure what the source for Greg's JavaAppLauncher actually looks like, did he change this plist key value as well?
The other possibility there might be that while the jars in $JAVAROOT were included automatically I also tried including folders in classpath. These were what I tried to add a ClassPath plist entry for. This was to use classpath loading of script (AppleScript,JRuby,Rhino) files as well as StringTemplate templates. Folders might get ignored?
Including some of these options in the demo version at least still seems like an idea to provide some verification that they do all function.
But folders don't work might be the only real issue there was with Greg's.
More information about the macosx-port-dev