RFR: 8286122: [macos]: App bundle cannot upload to Mac App Store due to info.plist embedded in java exe

[Michael Hall]

> On May 12, 2022, at 4:42 AM, Magnus Ihse Bursie <magnus.ihse.bursie at 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.