On Thu, 18 May 2023 06:06:05 GMT, Alan Bateman <[email protected]> wrote:
>> Hmm, most java bytecode (classfiles) aren't going to care about the >> endian-ness; in int is an int, etc. >> Runtime calls to extract int from byte[] is going to check a runtime flag; >> possibly static and optimization by HotSpot, etc. >> The Architecture enum was intending to capture essential build time >> attributes. >> If there is a need for more static attributes of a build, the current API >> doesn't cover that. > >> Hmm, most java bytecode (classfiles) aren't going to care about the >> endian-ness; in int is an int, etc. >> Runtime calls to extract int from byte[] is going to check a runtime flag; >> possibly static and optimization by HotSpot, etc. >> The Architecture enum was intending to capture essential build time >> attributes. >> If there is a need for more static attributes of a build, the current API >> doesn't cover that. > > The image writer needs to be told the endianness of the target platform, > usually the native order but can be overridden. As part of pull/11943, a new > resource file is added to map the value of the ModuleTarget class file > attribute (essentially $os-$arch) to the endianness to help cross linking. I > don't yet see how this will work with the changes in the this PR. Thanks for the hint! I've added a comment to https://github.com/openjdk/jdk/pull/11943 . ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14027#discussion_r1197984714
