On Fri, 20 Jan 2023 14:23:13 GMT, Jaikiran Pai <j...@openjdk.org> wrote:
> Right now the ModuleTarget class file attribute is not enough but a short > term fix might be for jlink to have a simple mapping of known ModuleTarget > values to endianness. Overall, it's probably low priority as the most likely > users of this will be environments building for embedded platforms. I've now updated this PR to revert the previous commits and instead follow this suggestion to infer the endianness of the target platform while generating the image. The updated PR now continues to allow users to provide `--endian` option while generating an image through `jlink`. If any value is provided for that option, the image generation will continue to honour that value. However, if no value is provided for that option, then during image generation, we will determine the endianness of the target platform, by using the (OpenJDK specific) `ModuleTarget` attribute of target `java.base` module's `module-info` class. This determination is best-effort and if the value cannot be determined, then we default to the current platform's endianness (like we have been doing so far). This commit hardcodes the mapping between a `ModuleTarget`'s architecture and endianness and this mapping is borrowed from what we already do in the OpenJDK build file https://github.com/openjdk/jdk/blob/master/make/autoconf/platform.m4#L26 No new tests have been added in this change, because I couldn't think of a way to test the cross platform `jlink` execution. Existing tests in `test/jdk/tools/jlink` continue to pass with this change. I've triggered our CI runs to run the tiered tests to make sure nothing regresses. The commit in this PR doesn't deprecate the --endian option and I think we can do that as a separate issue. ------------- PR: https://git.openjdk.org/jdk/pull/11943
