On Wed, 29 Mar 2023 01:40:36 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 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 > See draft PR #14063 for a proposal Hello Roger, I had a look at that draft PR. The introduction of `Architecture.byteOrder()` and `Architecture.lookupByName(archName)` in that PR, I believe is going to help us here. I could then read the `ModuleTarget` attribute and use the `Architecture.lookupByName()` to get hold of the target architecture and thus its endianness through `Architecture.byteOrder()`. That would then mean we no longer need the `target.properties` file that was previously proposed in this PR. I haven't had a chance to refresh this PR to resolve the merge conflicts. I hope to get to it soon. ------------- PR Comment: https://git.openjdk.org/jdk/pull/11943#issuecomment-1561023227
