On Fri, 25 Jun 2021 13:30:56 GMT, Yi Yang <yy...@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
