> 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&gt;) <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 
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. 

Reply via email to