RFR: 8286122: [macos]: App bundle cannot upload to Mac App Store due to info.plist embedded in java exe

[Michael Hall]

Alexander

> On May 11, 2022, at 11:38 PM, Alexander Matveev <alexander.matveev at oracle.com> wrote:
> 
> Hi Michael,
> 
>> On May 11, 2022, at 3:17 PM, Michael Hall <mik3hall at gmail.com> wrote:
>> 
>> Is this restricted somehow to Mac App Store applications?
> Yes, helper tools (in our case JDK native commands) in Mac App Store applications cannot use same bundle ID as another application. Since we have bundle ID embedded in native commands multiple applications cannot use it without updating each native command with unique bundle ID and since they embedded inside executable I do not see how it would be possible to change during packaging.

Possibly not during packaging but during the jdk build of the native commands? Somehow the Info.plist must be getting embedded and a bundle id provided. I’m not sure where or how. But one way to get uniqueness if the id is provided to embed the Info.plist in the native command executable compile/link  would be to include the command as part of the identifier. Something like CFBundleID = java.native.cmd or CFBundleID = javac.native.cmd. 

>> 
>> Is a warning issued as stripping native commands  may break application functionality?
> No, error will be issues and jpackage will exit with error if —mac-app-store arguments is used and provided runtime has native tools or user did not specified --strip-native-commands to jlink.

A warning might be sufficient if the commands are included accidentally by the user unintentionally omitting the —strip-native-commands with the jlink options. Then just force the —strip-native-commands option. It might be the application will just lose some non-critical functionality even if they meant to have the native command included.

>> Is it not possible for the user to provide their own Info.plist with  a different bundle identifier that doesn’t collide?
> Not possible due to native commands have embedded Info.plist.

Maybe I’m misunderstanding the conflict. Are the commands conflicting with the application level Info.plist or with each other? I believe jpackage usually has a mechanism where a substitute Info.plist can be used if the conflict is with the application level. If multiple commands are conflicting with each other this won’t work.

>> 
>> I’m not real familiar with the build process. But would it be possible for the user to build their own jdk that substitutes something else for the colliding identifier that gets embedded?
> Yes, it should be possible and in theory such JDK with native commands can be used. However, current fix will not allow such JDK build, since we checking for presence of “bin” folder and not if ID is actually unique. To work around this limitation user can package without native commands first, then add native commands and re-sign application.

Signing is currently an integrated part of the process. I thought about making an enhancement request to have it possible to do it stepped. First build the application, then allow the user to post-process that. Maybe run a tool/script to modify the application level Info.plist file. Then allow a second final step that does the signing. I don’t remember if I actually made that enhancement request. But currently there is no way with jpackage to standalone sign the application is there? I think this is somewhat involved with the application bundle being iterated and for one thing each jar being separately code signed? I think it took a release or two of the command to get this correct. So I doubt Xcode could manage it. Is there a way to do the signing standalone with jpackage that I am not aware of?

If I didn’t do an enhancement request on this I could, if you think jpackage could manage it?
 
> 
>> Or just change it in the current build so it doesn’t collide? With the application or whatever one it is colliding with.
> Not possible, since ID should be unique per application.

Possibly you are misunderstanding me here I think you already indicated the could be done ‘in theory’. It still seems possibly the correct ‘fix’. Change the build so uniqueness is not an issue.
> 
> Thanks,
> Alexander

Thanks,
Mike