Need reviewer: JDK 8 CR for Support Integer overflow
Roger.Riggs at oracle.com
Mon Feb 6 21:15:22 UTC 2012
On 02/03/2012 10:23 AM, Stephen Colebourne wrote:
> I prefer the method naming safeAdd/safeNegate/safeMultiply (I think
> they are a lot clearer), but can live with the ones proposed (which
> are somewhat linked to BigInteger/BigDecimal).
The method names should start with the operation.
> I would like to see source code comments explaining why the algorithm
> works in the final version in OpenJDK. Thats because OpenJDK code is
> used by everyone to read and understand what is good Java code, and
> for debugging. Being given a clue to understand the algorithm is
> highly desirable.
yes, I will add comments to describe the implementation and refer to
Hackers Delight Section 2-12
> Most of the methods do not specify the arguments in the exception, but
> the multiply methods do. It should be consistent one way or the other.
Simplify the exception arguments; if these exceptions occur debugging
will be required by examining the source code or using a debugger
so the message content is not a significant factor in debugging.
> It may be worth considering (by testing) if methods taking one long
> and one int are worthwhile. More efficient implementations of the
> algorithms may be possible, but at the expense of additional API size.
Since there is no support in the bytecode for combinations of int and long
handcoding the mixing would make it harder to optimize the code to the
operations. Widening to long enables optimizations for those
operations to be used.
> Separately but related, there are missing methods in BigInteger,
> longValueExact() and intValueExact()
BigInteger provides a bitLength method than be tested to see if the result
would overflow. That's a better API than an ArithmeticException and is
for the developer to work with.
More information about the core-libs-dev