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

Aren't we embedding this bundle ID in every launcher, so you would need a <launcher>.template for each possible launcher that could be included in an app?

What I think we need to do is first evaluate if we actually need to embed this bundle ID in the executables at all, or rather, what would the consequences be if we didn't. My understanding is that we only do this to be able to run them outside of a bundle directory structure, but this would need some pretty thorough testing of course. If we are to generate a special set of launchers for jpackage, maybe all we need to do is not embed any bundle ID in them, as they are meant to only be used within a jpackaged app, so they should be covered by Info.plist files anyway.


Reply via email to