JDK 8 code review request for initial unsigned integer arithmetic library support

[Ulf Zibis]

Thanks for your feedback.

Am 21.01.2012 01:31, schrieb Joseph Darcy:
> 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
>> <code>'\u0030'</code>
>> 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.
I only meant the new lines, where you have a mixture of {@code...} and <code>...</code>.
Then IMHO better exclusively use <code>...</code>.

>
>>
>> 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.
Aha! But I think, people who deal with unsigned bits know that, and otherwise they puzzle, what 
about the hack is the miracle behind the cast, like me ;-)

>
>
>>
>> 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.
I think, this is the VM's deal. Otherwise, people, who intentionally use short type, would have to cast:
short s = (short)toUnsignedInt(byte x);

>
>>
>> superfluous:
>>     public static int 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      * <li>The value represented by the string is larger than the
>>  624      * largest unsigned {@code int}, 2<sup>32</sup>-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.
There is a difference:
toHexString performs: transform _to_ hex string
but...
toUnsignedInt performs: transform _as/from_ unsigned

-Ulf