> On May 12, 2022, at 4:42 AM, Magnus Ihse Bursie
> <magnus.ihse.bur...@oracle.com> wrote:
>
>> Some further spelunking reveals the issue. Consider this:
>>
>> % otool -s __TEXT __info_plist -v
>> APP_NAME.app/Contents/runtime/Contents/Home/bin/java
>> …
>> <dict>
>> <key>CFBundleIdentifier</key>
>> <string>net.java.openjdk.java</string>
>> …
>> </dict>
>> </plist>
>>
>> This is an obscure corner case in the macOS bundle story: A standalone tool,
>> like `java`, which isn’t in a bundle structure, and thus can’t have a
>> standalone `Info.plist` file, can put its information property list in a
>> `__TEXT` / `__info_plist` section within its executable. And it seems that
>> the folks who created your Java runtime did just that.
>>
>> Given that, the Mac App Store error is valid: You are trying to submit an
>> executable whose bundle ID matches some existing app.
>>
>> To get around this check you’ll need to give `java` a new bundle ID. That’s
>> not easy to do. This `__TEXT` / `__info_plist` section is set up by a linker
>> option (see `-sectcreate` in <x-man-page://1/ld>) <x-man-page://1/ld%3E)>
>> and there’s no good way to modify it after the fact [1].
I had read this but possibly didn’t grok the issue myself. If I understand
correctly now the conflict isn’t within the application but across applications
to some other application that has already been added to the Mac App Store that
included the commands with the given CFBundleIdentifier. A solution like
including a bundle identifier something like net.java.openjdk.MYAPP.java would
be possible at packaging time but not at build time.
To fix this at build time you would need to generate a name unique to each
installed jdk. Including release net.java.openjdk.JDK_RELEASE.java might avoid
some conflicts but would still be open to conflict for two applications at the
same release. So it can’t be addressed ‘before the fact’ either. The only thing
I am currently thinking of that might work would be include a replaceable part
in the identifier. So something like
net.java.openjdk.java.XXXXXXXXXXXXXXXXXXXXXX
Where jpackage could include something to change the XXXXX…. to a unique
application name. If you don’t change the string size you could probably avoid
some of the resizing issues Apple DTS mentions. Whether there is a standard
Apple tool to do this I don’t know.
