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. Thanks, Alexander
