> 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 six additional commits since the last revision: - include a test to verify that an explicitly specified --endian value which matches the target platform's endianness, creates the image correctly - Roger's suggestion - use Architecture.lookupByName() instead of dealing with alias name replacements - Determine the target platform outside of the ImageHelper and just pass it the determined target platform - minor formatting change - align parameters - Mandy's suggestion - rename (and update comments) isJavaBaseFromCurrentPlatform to isJavaBaseFromDefaultModulePath - Mandy's suggestion - no need to store endian in JLinkConfiguration ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11943/files - new: https://git.openjdk.org/jdk/pull/11943/files/962d542d..733e7b50 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11943&range=19 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11943&range=18-19 Stats: 235 lines in 6 files changed: 119 ins; 101 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/11943.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/11943/head:pull/11943 PR: https://git.openjdk.org/jdk/pull/11943
