On Mon, 13 Mar 2023 10:32:06 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: > > - 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 src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java line 897: > 895: (PrivilegedExceptionAction<Boolean>) () -> > Files.isSameFile(javaBasePath, > 896: > currentPlatformJmods.resolve(Path.of("java.base.jmod")))); > 897: } catch (PrivilegedActionException e) { jlink doesn't run with a security manager so no need for the AccessController.doPriv. Assuming the name of the jmod file is probably okay. src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java line 976: > 974: default -> null; > 975: }; > 976: } To add to Jim's comment, the other thing we think about here is mapping the value of the ModuleTarget attribute to endianness, meaning don't parse it to extract the architecture. ------------- PR: https://git.openjdk.org/jdk/pull/11943
