On Sat, 18 Mar 2023 13:17:04 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 with a new target base due to a > merge or a rebase. The incremental webrev excludes the unrelated changes > brought in by the merge/rebase. The pull request contains 20 additional > commits since the last revision: > > - Mandy's suggestion - pass along target platform to the DefaultImageBuilder > to prevent reparsing the value from the ModuleTarget > - Mandy's suggestion to use Platform class for additional arch support. > Plus, Jim's suggestion to use a runtime resource for endianness mapping > - merge latest from master branch > - don't hardcode the .jmod extension while determining java.base module > location > - Path.resolve(String) instead of Path.resolve(Path) > - no need for security manager checks in jlink > - only include known supported arch > - Alan's suggestion - look into the ModuleTarget attribute in > module-info.class only if this is a cross-platform image generation > - missed ppc64 from the arch mapping > - undo unintentional copyright year change > - ... and 10 more: https://git.openjdk.org/jdk/compare/520eaa6f...f4b71700 Existing tests in `test/jdk/tools/jlink` and `test/jdk/tools/jimage` continue to pass with these changes and a manual test of building a cross platform image shows that it picks up the correct endianness of the target platform (and fails with an error if the target platform's endianness isn't known) ------------- PR: https://git.openjdk.org/jdk/pull/11943
