RFR: 8269383: (bf) ByteOrder should expose methods to test if platform is big or little endian

Yi Yang yyang at openjdk.java.net
Fri Jun 25 15:34:01 UTC 2021


On Fri, 25 Jun 2021 13:30:56 GMT, Yi Yang <yyang at openjdk.org> wrote:

> Hi, can I have a review of this change that adds two new utility methods for java.nio.ByteOrder? Looking through the whole JDK codebase, most calls of ByteOrder.nativeOrder() is to check if the underlying platform is little-endian/big-endian(e.g. #4596 ). There is no reason to only provide ByteOrder.nativeOrder while leaving big-endian/little-endian checking methods blank. For most cases(in JDK or in user code), we want a checking(byte order) rather than retrieving(byte order).
> 
> Thanks!

Hi Chris,

> Is there any other potential benefits, performance or otherwise, that than be achieved by such an API?

Unfortunately not. It's more like the enhancement of API expressiveness. Since these operations are trivial, these APIs will not improve/degrade the performance. Although we can use `@IntrinsicCandidate` to intrinsify it for potential? performance benefit, but I don't think it's necessary at present(and in future...), but I think they are good candidates of `@ForceInline` annotations.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4595


More information about the core-libs-dev mailing list