RFR: 8304006: jlink should create the jimage file in the native endian for the target platform [v5]
Alan Bateman
alanb at openjdk.org
Mon Mar 13 14:46:26 UTC 2023
On Mon, 13 Mar 2023 10:32:06 GMT, Jaikiran Pai <jpai at 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
More information about the core-libs-dev
mailing list