On Mon, 13 Mar 2023 16:22:30 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: > > don't hardcode the .jmod extension while determining java.base module > location src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java line 834: > 832: // find the target platform's arch and thus its > endianness from the java.base > 833: // module's ModuleTarget attribute > 834: Optional<ResolvedModule> javaBase = > cf.findModule("java.base"); `ModuleTarget` is read by `DefaultImageReader::storeFiles` as well. Perhaps it should be refactored so that the target `Platform` can be passed to `DefaultImageBuilder`. src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java line 953: > 951: // and supported for creating an image through jlink. Else > returns null. > 952: private static ByteOrder getNativeEndianOfTargetPlatform(String > targetPlatform) { > 953: int index = targetPlatform.indexOf("-"); // of the form > <operating system>-<arch> `Platform::parsePlatform` is the utility method to parse `ModuleTarget`. It can be updated to include additional architectures. ------------- PR: https://git.openjdk.org/jdk/pull/11943
