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

Joseph Darcy joe.darcy at oracle.com
Sat Jan 21 00:35:30 UTC 2012


On 1/19/2012 8:05 AM, Ulf Zibis wrote:
> Am 19.01.2012 07:43, schrieb Eamonn McManus:
>> Ulf Zibis writes:
>> > What about:
>> >  private static final BigInteger BEYOND_UNSIGNED_LONG = 
>> BigInteger.valueOf(1).shiftLeft(64);
>> >  private static BigInteger toUnsignedBigInteger(long i) {
>> >      BigInteger result = BigInteger.valueOf(i);
>> >      if (i < 0L)
>> >          result = result.add(BEYOND_UNSIGNED_LONG);
>> >      return result;
>> >  }
>>
>> That's a nice idea! But the problem is that it would mean that 
>> BigInteger.class would be loaded as soon as Long.class is, which I 
>> think is undesirable.
> Thanks for the critic. I didn't see that.
> The problem could be easily avoided if method 
> toUnsignedBigInteger(long i) would be moved to class BigInteger as 
> unsignedValueOf(long i), as I additionally noted in my last post.
>
>> However it does make me think that we could change...to this:
>>
>>     if (i >= 0L) {
>>         return BigInteger.valueOf(i);
>>     } else {
>>         return BigInteger.valueOf(i & Long.MAX_VALUE).setBit(63);
>>     }
> Another nice idea!
> But again, moving the entire method to BigInteger would additionally 
> avoid to clown around with the available BigInteger's public APIs. 
> Having the method at BigInteger would allow elegant direct access to 
> the private value fields.
>
>

If the operation in question starts becoming a bottleneck, these 
alternate implementations can be explored.  In the meantime, I plan to 
stick with the straightforward code and not setup the infrastructure 
needed to get at BigInteger internals.

Thanks,

-Joe



More information about the core-libs-dev mailing list