> On May 11, 2022, at 11:38 PM, Alexander Matveev 
> <> wrote:
> Hi Michael,
>> On May 11, 2022, at 3:17 PM, Michael Hall <> 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


Reply via email to