On Mon, 27 Mar 2023 11:07:34 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: > > - update the property key names in target.properties to use ".endianness" > suffix > - remove @since 21 on internal class src/jdk.jlink/share/classes/jdk/tools/jlink/internal/Platform.java line 57: > 55: if (platform.isEmpty()) { > 56: throw new InternalError("Incorrect key '" + key + > "'"); > 57: } If you scan all entries, this can probably check the value is valid (`little` or `big`) and store them in a `Map<String, ByteOrder>` so that `parsePlatform` can simply get the byte order by `KNOWN_ENDIANNESS.get(platformString)`. Or the other option can just be doing in the `parsePlatform` method and not needed to scan all entries. String v = KNOWN_ENDIANNESS.getProperty(platformString + ENDIANNESS_KEY_SUFFIX); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/11943#discussion_r1149519476
