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

[Roger Riggs]

On Wed, 29 Mar 2023 01:40:36 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:
> 
>  - cleanup test - rename method and update code comment as suggested by Alan
>  - Rename KNOWN_ENDIANNESS to PLATFORM_PROPERTIES

It seems that the endian-ness is intrinsic to the architecture, as it support for 64-bit addresses. Its not just an ancillary attribute.
This PR makes the case that identifiers for os and architecture need to cover the cross-platform uses, not just the current runtime.
Including the endianness in the architecture names/enums seems like a simple and consistent way to cover the case.
The class file attribute ModuleTarget and the jdk.internal.util.Architecture namespace should be consistent or the same. 
I'd be happy to propose an update to the jdk.internal.util.Architecture to expand the namespace and provide methods for endianness and address size.

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

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