Alexander > On May 11, 2022, at 11:38 PM, Alexander Matveev > <alexander.matv...@oracle.com> wrote: > > 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.
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
