Using unsigned library work in the JDK

[Ulf Zibis]

Am 26.01.2012 17:11, schrieb Roger Riggs:
> Is there any performance impact of the method call vs the &0xff?
> Hotspot will in-line the code but for VMs with less sophisticated
> optimizations it will be a net loss.
+1
At least in interpreter and maybe -client compiler the new code would have performance impact.

> Its unfortunate that between the method name and need to qualify
> with the class (or use static imports) that the code is longer and not always clearer.
+1
- static import could become ambiguous using Byte.toUnsignedInt() + Short.toUnsignedInt() at same time.
+ The shortest I can think:
Short.unsigned(byte)
Integer.unsigned(short)
Long.unsigned(int)
BigInteger.unsigned(long)
+ Nothing would be ambiguous, using static import.

> The existing idiom for unsigned byte is easy enough to recognize.
> For the places where multiple bytes are assembled into short or integer,
> a new method with a specific purpose would be a clearer modification to the code.
+1
+ Would be an ideal candidate for intrinsification
+ See similar (vice versa): http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6914113
- For type short a cast is needed using current implementation:
short s = (short) Byte.toUnsignedInt(byte)

> Seeing the use in the IO context, the method names may be more useful if they reflect the data 
> taken from the argument.  For example,   asUnsignedByte(buffer[i]) .
+++ 1

> But I/O is more about assembling bytes and less about unsigned arithmetic.
Maybe java.io.Bits would be the right home for things like that.


-Ulf