On Wed, 11 Jan 2023 13:19:32 GMT, Jaikiran Pai <j...@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. > When jlink is cross linking, as in creating a run-time image for a different > target platform, then I think we should strive to have it create the jimage > file in the native endian for the target platform. .... Instead I think we > need to consider determine the endian from the target java.base module. Having jlink to determine the endianness for the target platform is a good idea. This will improve its usability and `--endian` option could be dropped. Currently jlink looks at the `ModuleTarget` attribute to determine the target platform, which can be extended to include endianness. > Right now the ModuleTarget class file attribute is not enough but a short > term fix might be for jlink to have a simple mapping of known ModuleTarget > values to endianness. This is a viable short-term solution. ------------- PR: https://git.openjdk.org/jdk/pull/11943
