> On Sep 20, 2022, at 5:50 PM, Michael Hall <mik3h...@gmail.com> wrote: > > Still you could use post-processing to add whatever java binary executable > commands you wanted. This again would mean changes to the embedded jdk that > might have signing side effects. I haven’t tested.
Thinking about this I looked at my application that includes java commands and saw that currently I include all. And all appear to be of fixed size. So I assume some kind of launcher stub? I then remembered [macos]: App bundle cannot upload to Mac App Store due to info.plist embedded in java exe https://bugs.openjdk.org/browse/JDK-8286122 <https://bugs.openjdk.org/browse/JDK-8286122> The bug being due… > ITMS-90511: CFBundleIdentifier Collision - The Info.plist CFBundleIdentifier > value 'net.java.openjdk.java' of 'java' is already in use by another > application. This because the launcher stub includes it’s own Info.pliat’s always using the same CFBundleIdentifier If I understand the resolution correctly… https://github.com/openjdk/jdk17u-dev/commit/6a4b6220f8dc184f408f1295865ed0ad2e3710ca <https://github.com/openjdk/jdk17u-dev/commit/6a4b6220f8dc184f408f1295865ed0ad2e3710ca> This effectively prohibits jpackage applications going to the App Store from using java native commands by disallowing the jlink option. I realize this issue is closed and probably not yours to resolve. But wouldn’t it be possible to simply make the CFBundleIdentifier unique? Maybe a hash of command name and application name, something like… Hash(“java”+”MyCommandUsingMacAppStoreApp”) I don’t think the identifiers for the embedded commands need to be meaningful to the developer or anyone else. A good hash should pretty much eliminate collisions. My apologies if I’m simply repeating something dismissed in prior discussion.
