Re: 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>'&#92;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