jpackage OS X classpath

Michael Hall mik3hall at
Tue Jan 29 17:50:16 UTC 2019

I figured out for the time being how I can programmatically handle setting security that might be cross-platform for my application.

Past that it doesn’t seem to be finding resources off the class loader that it should be…

With this…

		ClassLoader cl = Thread.currentThread().getContextClassLoader();
		syslog.println("cl is " + cl + "\nuser.dir " + System.getProperty("user.dir") + "\nCP> " + System.getProperty("java.class.path"));		

I get this…

cl is jdk.internal.loader.ClassLoaders$AppClassLoader at 55054057
user.dir /Users/mjh/HalfPipe/HalfPipe_jpkg/outputdir/
CP> /Users/mjh/HalfPipe/HalfPipe_jpkg/outputdir/
…and so on...

Only the first path in java.class.path is absolute - to the main jar. Would this break if the application is moved? The other paths are relative. I notice user.dir is now default set directly to the Java directory within the app. I assume this is how relative is supposed to work. This is again a change from legacy OS X java app’s. Prior to the OS X port I think Apple set this to the parent directory of the application itself. With AppBundler set up during the port it was set to the user home directory. I think for security concerns? (App’s should usually be in the Application directory, this should not be written to by the application). So this is another change that legacy app’s could have issues with. 

It might be a thought to document some of the differences to legacy java applications somewhere? 

Anyhow, I put the resources that I am currently not finding in the resource.jar shown above. I thought some testing with non-jpackage apps showed this would work. These used to be in the “Classes” directory as mentioned in an earlier post. A rather obscure feature probably not many app’s took advantage of. But I am now not finding them in the jpackage resource.jar for some reason still to be determined. 


	  				BufferedReader rdr = new BufferedReader(new InputStreamReader(cl.getResourceAsStream("Scripts/loader.js")));

org.mozilla.javascript.EvaluatorException: Couldn't open file "Scripts/mm.js". (unnamed script#1)
	at org.mozilla.javascript.DefaultErrorReporter.runtimeError(
	at org.mozilla.javascript.DefaultErrorReporter.error(
	at org.mozilla.javascript.Context.reportError(

Actually what it says it’s not finding isn’t loader.js but a script that loader.js should load? So maybe again this is some difference in how a nested load works? Again, it would be different application behavior somehow if so.

More information about the core-libs-dev mailing list