On Thu, 23 Mar 2023 01:46:47 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. > > Jaikiran Pai has updated the pull request incrementally with one additional > commit since the last revision: > > ARM is 32 bit as per platform.m4 in OpenJDK build Thank you Mandy for the review, I've updated the PR with the changes that you suggested. Existing jtreg tests in `test/jdk/tools/jlink` `test/jdk/tools/jimage` continue to pass and a manual test shows that for cross platform jlink, the code picks up the endianness correctly and also throws an error if an explicit endianness doesn't match the java.base module's target platform. ------------- PR Comment: https://git.openjdk.org/jdk/pull/11943#issuecomment-1480469900
