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

Joe Darcy joe.darcy at oracle.com
Sat Jan 14 18:58:04 UTC 2012


Hi Mike,

On 01/13/2012 09:51 PM, Mike Duigou wrote:
> Really cool stuff Joe.
>
> One initial note:
>
> parseUnsigned*() returns a signed value that may not be able to hold the entire result. I would rather see a larger size be returned to be sure that subsequent operations don't have to be special cased for>  MAX_VALUE. At minimum some documentation describing the interpretation of negative return values is needed.

The intention of the fooUnsigned methods is that they interpret the 32 
or 64 bit value as unsigned.  So for example, for parseUnsigned, rather 
than recognizing strings representing values between -2^31 and (2^31)-1, 
the method recognizes values between 0 and (2^32)-1, mapping results 
between 2^31 and (2^32)-1 to what are usually thought of as the negative 
values.

I'll take another pass over the new javadoc to try to make this clearer.

Thanks,

-Joe

>
> Mike
>
> On Jan 13 2012, at 21:26 , Joe Darcy wrote:
>
>> Hello,
>>
>> Polishing up some work I've had *almost* done for a long time, please review an initial take on providing library support for unsigned integer arithmetic:
>>
>>     4504839 Java libraries should provide support for unsigned integer arithmetic
>>     4215269 Some Integer.toHexString(int) results cannot be decoded back to an int
>>     6322074 Converting integers to string as if unsigned
>>
>>     http://cr.openjdk.java.net/~darcy/4504839.1/
>>
>> For the first cut, I've favored keeping the code straightforward over trickier but potentially faster algorithms.  Tests need to be written for the unsigned divide and remainder methods, but otherwise the regression tests are fairly extensive.
>>
>> To avoid the overhead of having to deal with boxed objects, the unsigned functionality is implemented as static methods on Integer and Long, etc. as opposed to introducing new types like UnsignedInteger and UnsignedLong.
>>
>> (This work is not meant to preclude other integer arithmetic enhancements from going into JDK 8, such as add/subtract/multiply/divide methods that throw exceptions on overflow.)
>>
>> Thanks,
>>
>> -Joe
>>
>>




More information about the core-libs-dev mailing list