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 src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java line 823: > 821: if (order != null) { > 822: this.order = order; > 823: String targetPlatformVal = > readJavaBaseTargetPlatform(cf); Thanks for the update. This should also do the fast-path check `isJavaBaseFromCurrentPlatform(javaBasePath)` as in line 838-860. I suggest to refactor line 838-860 to return the target platform (either runtime platform or from java.base in the given module path). I also suggest to include `endianness` in the `Platform` record class. I sent you a patch offline with these suggestions. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/11943#discussion_r1146654036
