JDK 8 code review request for initial unsigned integer arithmetic library support (original) (raw)

Joseph Darcy joe.darcy at oracle.com
Sat Jan 21 00:31:20 UTC 2012

On 1/18/2012 7:52 PM, Ulf Zibis wrote:

Am 18.01.2012 03:54, schrieb Joe Darcy:

I've posted a revised webrev at

http://cr.openjdk.java.net/~darcy/4504839.2 Instead '\u0030' you can use {@code '\u005Cu0030'}

That is a fine cleanup, but I'll do a bulk conversion of all the instances of that pattern later on under another bug.

Byte: ===== 459 public static int toUnsignedInt(byte x) { 460 return ((int) x) & 0xff; 461 } This should be good enough (similar at Short, Integer): 459 public static int toUnsignedInt(byte x) { 460 return x & 0xff; 461 } (This notation if regularly used in sun.nio.cs coders.)

I think the current code more explicitly indicates the intention of the method's operation to more casual readers less familiar with the details of primitive widening conversions, etc.

missing: public static short toUnsignedShort(byte x)

That omission was intentional. The language and VM only really support arithmetic on int and long values, not short or byte, so I only providing methods to widen to int and long.

superfluous: public static long toUnsignedInt(byte x) public static long toUnsignedLong(byte x) (similar at Short) one can use: int i = toUnsignedShort(x) long l = toUnsignedShort(x) (similar at Short) Integer: ======== 623 *

  • The value represented by the string is larger than the
    • 624 * largest unsigned {@code int}, 232-1. If you format {@code int}, then you speak about the java type int, which is always signed, never unsigned. IMO you should better write 'unsigned 32-bit integer". (similar at Long)

    Due to similar feedback, I've made various clarifications to the javadoc, but the basic situation is that the "fooUnsigned" methods interpret the bits as unsigned values, as already done in toHexString and related methods.

    Thanks,

    -Joe

    More information about the core-libs-dev mailing list