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

[Magnus Ihse Bursie]

On 2022-05-12 13:17, Michael Hall wrote:
> 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. 

Yes, that is indeed how I also interpret this. Presumably, the very 
first developer to submit a jpackaged application to App Store (from 
what I can tell now OpenJDK itself is not present there, which I 
mistakenly believed before) got everything working without troubles, but 
blocked all other developers from submitting their apps.

> 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.

As you say, we're a bit in a bind since the java executable needs to be 
created when the JDK is built, but the bundle ID needs to be determined 
when jpackage is run (and a suitable, per-application ID can be 
created), and there is no standard tooling to update the bundle ID after 
build time.

I believe what you are describing is exactly solution #2 suggested by 
the Apple engineer. I don't think that would be horribly difficult to 
achieve, though. Sure, it's a bit of a hack, but not the ugliest I've 
seen in my days. If we go down this route, I suppose we do something 
like this:

1) When building the JDK, we create an additional copy of the java 
executable, and store it with the jdk.jpackage resources. Let's call it 
java.template, for the sake of it. This is identical to the real 
bin/java except for the fact that it contains a different bundle ID, 
with a large enough padding field, like XXXXX...  This way, we don't 
have to mess around with the real java executable for the JDK.

2) At jpackage time, this java.template file is installed instead of 
bin/java, and the padding field is replaced by a unique value. The java 
executable is small (33kB on macOS, currently) so a simple search 
through the binary field for the pattern is likely to work alright. As 
long as there are no checksums being broken, this should be straightforward.

My primary suggestion would to be to use an UUID for the unique ID. They 
are of fixed length, are for all intents and purposes unique and you can 
conjure them up from your hat. (An alternative is that the user needs to 
specify a unique ID, but that is probably a less ideal solution.) 
Presumably, we can have some kind of prefix like "org.openjdk.jpackage." 
before the UUID to make them a bit understandable, if someone where to 
inspect the package metadata.

This seems like a fully workable solution to me. However, I'd really 
like to understand option #1 better, which was: "Package the `java` 
executable in a standard bundle, replacing 
`runtime/Contents/Home/bin/java` with a symlink to that."

I don't know what a "standard bundle" is, or how you would go around to 
package the java executable in one. But on the surface, it sounds much 
nicer than binary editing.

I also don't understand if that means that the standard bundle needs to 
be created at jpackage time, so it gives us the chance to set a proper 
ID, or if the standard bundle can be created at build time, and then the 
existence of this bundle just makes Apple avoid the bundle ID collision 
checks. Or if I'm just misunderstanding it all...

/Magnus