On Thu, 17 Sep 2026 23:20:27 GMT, Justin Lu <[email protected]> wrote:
> 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). This pull request has now been integrated. Changeset: bf2e6ce9 Author: Justin Lu <[email protected]> URL: https://git.openjdk.org/jdk/commit/bf2e6ce918aa525b8a114b82dc056dd3c33703ce Stats: 75 lines in 2 files changed: 54 ins; 0 del; 21 mod 8392400: CompactNumberFormat.format(BigDecimal) formats inconsistently compared to format(double) Reviewed-by: naoto ------------- PR: https://git.openjdk.org/jdk/pull/32933
