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