Bundled app launcher changes

Mike Swingler swingler at apple.com
Fri Feb 10 18:16:19 PST 2012

On Feb 10, 2012, at 6:05 PM, Michael Hall wrote:

> On Feb 10, 2012, at 7:47 PM, Mike Swingler wrote:
>> Perhaps the tag name <classpath> is subject to too much misinterpretation. Would <resource classpath=true> make it clear that it's a resource that should be copied into (whatever.app)/Contents/Java/, and may or may not be put on the apps classpath in the Info.plist?
>> If the classpath=true attribute is set, then a $JAVAROOT/myStuff.jar entry will be appended into the apps runtime classpath VM argument.
>> Would that syntax be more clear?
> Not up to me but I don't think that would make it any clearer for me.
> I would start thinking in terms of the old Contents/Resources/Java structure again and wondering where the Resources directory got off to.
> I'm just trying to understand if $JAVAROOT classpath entries will continue to be supported by the launcher?
> I thought they probably wouldn't be. They aren't really needed unless you want to allow the application to point to external absolute path jars is it? 
> Embed everything in fixed relative paths that is not system and who needs plist classpath entries?
> But if you're saying $JAVAROOT is still a supported option then it must be handled by the launcher so my question is answered and that practice continues along the lines of JavaApplicationStub.
> Clear enough if that is instead the case?

I believe that the new stub still macro still expands $JAVAROOT, but it expands to (app)/Contents/Java instead of (app)/Contents/Resources/Java. We don't want actual mach-o executable (or .jars for that matter) in (app)/Contents/Resources for code signing reasons.

Please keep in mind that compatibility with old JavaApplicationStub should be considered a non-goal of this project, but it was a useful starting point for the next generation of this technology, so you will obviously see echoes of it's design in places.

The classpath entries written in the new Info.plist should always reference inside the app, since any discovery of existing on-system resources needs to be done at runtime and should not fail an application's launch.

Make sense?
Mike Swingler
Apple Inc.

More information about the macosx-port-dev mailing list