JDK 8 code review request for initial unsigned integer arithmetic library support (original) (raw)

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 BEYONDUNSIGNEDLONG = BigInteger.valueOf(1).shiftLeft(64); > private static BigInteger toUnsignedBigInteger(long i) { > BigInteger result = BigInteger.valueOf(i); > if (i < 0L)_ _> result = result.add(BEYONDUNSIGNEDLONG); > 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.MAXVALUE).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