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
