On Thu, 31 Jul 2025 13:13:39 GMT, fabioromano1 <d...@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
