Re: RFR: 8269383: (bf) ByteOrder should expose methods to test if platform is big or little endian
On Fri, 25 Jun 2021 13:30:56 GMT, Yi Yang 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! Okay, it seems that more people do not agree with adding these APIs, I am going to close this proposal. - PR: https://git.openjdk.java.net/jdk/pull/4595
Re: RFR: 8269383: (bf) ByteOrder should expose methods to test if platform is big or little endian
On Fri, 25 Jun 2021 13:30:56 GMT, Yi Yang 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
Re: RFR: 8269383: (bf) ByteOrder should expose methods to test if platform is big or little endian
On Fri, 25 Jun 2021 13:30:56 GMT, Yi Yang 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! On the face of it, I do like this API enhancement. I've coded similar myself a number of times, well isBigEndian. Is there any other potential benefits, performance or otherwise, that than be achieved by such an API? - PR: https://git.openjdk.java.net/jdk/pull/4595
Re: RFR: 8269383: (bf) ByteOrder should expose methods to test if platform is big or little endian
On Fri, 25 Jun 2021 13:30:56 GMT, Yi Yang 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. > > Thanks! If this is accepted as a new enhancement, it will need a CSR. Personally, I don't see enough justification for such a convenience method, but this isn't my area, so my opinion doesn't carry any weight. - PR: https://git.openjdk.java.net/jdk/pull/4595
