RFR: 8077587: BigInteger Roots [v61]

[Raffaello Giulietti]

On Thu, 31 Jul 2025 13:13:39 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/math/MutableBigInteger.java line 1921:
>> 
>>> 1919:      * The contents of {@code this} are <em>not</em> changed. The value of {@code this}
>>> 1920:      * is assumed to be non-negative and the root degree {@code n >= 3}.
>>> 1921:      * Assumes {@code bitLength() <= Integer.MAX_VALUE}.
>> 
>> @rgiulietti This assumption could be dropped, if the shift methods of `MutableBigInteger` would accept `long` shift values too.
>
> @rgiulietti Could make sense to enhance `MBI.leftShift(int)` and  `MBI.rightShift(int)` to `MBI.leftShift(long)` and  `MBI.rightShift(long)`?

I think there are currently no use cases indirectly needing this by the publicly facing APIs. These are `nthRoot()` in `BigInteger` and, in the future, in `BigDecimal`: both assume a maximal bit length around 2^31, if I'm not mistaken.

The assumption in `MBI.nthRootRem()` is quite safe, as the only (current) usage is from `BI`.
We usually don't validate too much in internal classes (except when there are risks that could undermine the platform integrity), and assume they are used correctly and documented accordingly.
But if you feel uncomfortable, then I suggest to validate the input of `MBI.nthRootRem()` at method entry (maybe including the other assumptions). These checks are quite inexpensive compared to the rest of the computation.

Anyway, enhancing `MBI.[left|right]Shift(int)` would be better done in a separate PR, but only if there's some really compelling need.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24898#discussion_r2245415234