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

[erik.joelsson at oracle.com]

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