RFR: 8304006: jlink should create the jimage file in the native endian for the target platform [v5]

[Alan Bateman]

On Mon, 13 Mar 2023 15:34:51 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>>> jlink doesn't run with a security manager so no need for the AccessController.doPriv.
>> 
>> Thank you for that detail - I've now removed the SecurityManager checks from this newly introduced code.
>> 
>>> Assuming the name of the jmod file is probably okay.
>> 
>> Were you thinking of exploded builds? I'm not too familiar with exploded builds, but after you commented here about the `.jmod` extension, I checked the existing code in `JLinkTask` and I can see that we seem to allow the module to be packaged as a `.jar` too, like here https://github.com/openjdk/jdk/blob/master/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java#L834. Do you think this cross platform image creation would be relevant/used with exploded builds and if so, should I update the PR to address it?
>
>> Do you think this cross platform image creation would be relevant/used with exploded builds and if so, should I update the PR to address it?
> 
> Actually, now that I think about it, this `isJavaBaseFromCurrentPlatform()` method will get executed even for regular (same platform) image generation. Which means if the `java.base` module file doesn't end in a `.jmod` extension then this part of the code can run into `java.nio.file.NoSuchFileException` . I will generate an exploded build and see if anything needs to be done.

> Were you thinking of exploded builds? 

No, the exploded builds don't have the packages modules so you should get an error like this:

Error: --module-path is not specified and this runtime image does not contain jmods directory.

-------------

PR: https://git.openjdk.org/jdk/pull/11943