This PR addresses a rounding error for `CompactNumberFormat.format(BigDecimal)`, which occurs when the maximum fraction digits value is greater than the minimum fraction digits value.
For example, given a format with 0 minimum fraction digits and 2 maximum fraction digits and a `BigDecimal` of 21_534_567.20, the following behavior occurs. - `21_534_567.20` is first scaled to `21_534_567` to determine which compact divisor should be used - The millions pattern is selected, and the following division occurs -> `21_534_567` / `1_000_000`. During the division operation, the minimum fraction digits is inherited as the scale and applied to the resulting quotient which produces 22. Instead, the division should occur exactly, and `21_534_567` / `1_000_000` should produce `21.534567` which is then later rounded with the 2 maximum fraction digits to a value of `"21.53M"`. While the filed regression points out the BD path, this also occurs for the BI formatting path when the underlying value is greater than what a `long` supports and whose division result would produce a fraction. --------- - [x] I confirm that I make this contribution in accordance with the [OpenJDK Interim AI Policy](https://openjdk.org/legal/ai). ------------- Commit messages: - Cover BigInteger path - init Changes: https://git.openjdk.org/jdk/pull/32933/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=32933&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8392400 Stats: 41 lines in 2 files changed: 34 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/32933.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/32933/head:pull/32933 PR: https://git.openjdk.org/jdk/pull/32933
