On Wed, 11 Jan 2023 13:50:11 GMT, Alan Bateman <al...@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. > > src/java.base/share/classes/jdk/internal/jimage/ImageHeader.java line 199: > >> 197: * @throws IOException If any error occurred reading the contents >> of the image file. >> 198: */ >> 199: static ByteOrder tryDetectByteOrder(final Path imageFile) throws >> IOException { > > Style-wise I think I would try to keep it consistent with the existing code > if you can, meaning the noise/over-use of finals can mostly be removed if you > can. Done. I've updated the PR to remove all the `final` usage from this part of the code and made it consistent with the current code. ------------- PR: https://git.openjdk.org/jdk/pull/11943
