RFR 8154556: Use java.nio.ByteOrder instead of boolean value

Paul Sandoz paul.sandoz at oracle.com
Thu Apr 21 16:01:20 UTC 2016


> On 21 Apr 2016, at 16:43, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> 
> 
> On 21/04/2016 15:34, Paul Sandoz wrote:
>> Hi
>> 
>> Please review:
>> 
>>   http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8154556-vh-nio-byteorder/webrev/ <http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8154556-vh-nio-byteorder/webrev/>
>> 
>> This is a small tweak to the VarHandle API. The array and ByteBuffer related factory methods on MethodhHandles now accept a java.no.ByteOrder rather than a boolean value.
>> 
>> Use of java.no.ByteOrder is considered more readable in code that a boolean value, for express big, little or native endianness.
>> 
> The switch the ByteOrder looks okay, just wondering if have to check for null and then adjust @throws NPE in the javadoc too.
> 

I blindly copied the same behaviour from ByteBuffer.order:

/**
 * Modifies this buffer's byte order.
 *
 * @param  bo
 *         The new byte order,
 *         either {@link ByteOrder#BIG_ENDIAN BIG_ENDIAN}
 *         or {@link ByteOrder#LITTLE_ENDIAN LITTLE_ENDIAN}
 *
 * @return  This buffer
 */
public final ByteBuffer order(ByteOrder bo) {
    bigEndian = (bo == ByteOrder.BIG_ENDIAN);
    nativeByteOrder =
        (bigEndian == (Bits.byteOrder() == ByteOrder.BIG_ENDIAN));
    return this;
}

Was that behaviour intentional or an oversight? I am assuming the latter as it’s ambiguous what should happen if a third value, null, is passed.

I updated the webrev in place to throw an NPE.


> BTW: Is there a reason for "throws IllegalArgumentException"? This an unchecked so I assume not needed there (the @throws in the javadoc should be sufficient).
> 

I retained consistency with existing MH factory methods.

Thanks
Paul.



More information about the core-libs-dev mailing list