Hi Michael,

> On May 11, 2022, at 3:17 PM, Michael Hall <mik3h...@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.
> 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.
> 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.
> 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.

> 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.


Reply via email to