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

[Jaikiran Pai]

On Mon, 27 Mar 2023 11:07:34 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review for this change which proposes to fix the issue reported in https://bugs.openjdk.org/browse/JDK-8206890?
>> 
>> The `jlink` command allows a `--endian` option to specify the byte order in the generated image. Before this change, when such a image was being launched, the code would assume the byte order in the image to be the native order of the host where the image is being launched. That would result in failure to launch java, as noted in the linked issue.
>> 
>> The commit in this PR, changes relevant places to not assume native order and instead determine the byte order by reading the magic bytes in the image file's header content.
>> 
>> A new jtreg test has been added which reproduces the issue and verifies the fix.
>
> Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - update the property key names in target.properties to use ".endianness" suffix
>  - remove @since 21 on internal class

> I'll trigger a tier testing to make sure nothing breaks.

tier tests revealed that we have a `test/jdk/tools/jlink/plugins/CDSPluginTest.java` test which tries to simulate a cross platform jlink image generation. Given our changes in this PR, which only reads the `ModuleTarget` of java.base when the java.base module comes from a different file than the one in the current platform, this caused that simulation to fail and thus the test case failed. I've now updated the test to enhance it in the way in which simulates the cross platform image generation. That test and the rest of them in tier1, tier2 and tier3 all pass with this change.

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

PR Comment: https://git.openjdk.org/jdk/pull/11943#issuecomment-1486111886