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

[Jaikiran Pai]

On Sat, 18 Mar 2023 13:17:04 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 with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 20 additional commits since the last revision:
> 
>  - Mandy's suggestion - pass along target platform to the DefaultImageBuilder to prevent reparsing the value from the ModuleTarget
>  - Mandy's suggestion to use Platform class for additional arch support. Plus, Jim's suggestion to use a runtime resource for endianness mapping
>  - merge latest from master branch
>  - don't hardcode the .jmod extension while determining java.base module location
>  - Path.resolve(String) instead of Path.resolve(Path)
>  - no need for security manager checks in jlink
>  - only include known supported arch
>  - Alan's suggestion - look into the ModuleTarget attribute in module-info.class only if this is a cross-platform image generation
>  - missed ppc64 from the arch mapping
>  - undo unintentional copyright year change
>  - ... and 10 more: https://git.openjdk.org/jdk/compare/520eaa6f...f4b71700

Existing tests in `test/jdk/tools/jlink` and `test/jdk/tools/jimage` continue to pass with these changes and a manual test of building a cross platform image shows that it picks up the correct endianness of the target platform (and fails with an error if the target platform's endianness isn't known)

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

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