JDK-8276103 : DecimalFormat with 2 digits and default (HALF_EVEN) rounding returns wrong round
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.text
  • Affected Version: 8
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS: generic
  • CPU: generic
  • Submitted: 2021-10-27
  • Updated: 2021-11-02
  • Resolved: 2021-10-28
Related Reports
Duplicate :  
Description
ADDITIONAL SYSTEM INFORMATION :
- Mac with open JDK 13
- alpine docker with open JDK 13
- online compiler with JDK 8: https://www.tutorialspoint.com/compile_java_online.php

A DESCRIPTION OF THE PROBLEM :
Execute:
        java.text.DecimalFormat f = new java.text.DecimalFormat("0.00");
        System.out.println(f.getRoundingMode());

        for (int i = 0; i < 100; i++) {
            System.out.println(f.format(i + 0.915));
            System.out.println(f.format(i + 0.925));
        }

check results for values between 8 to 64 as opposed to other results.

If you change 0.915 to 0.015 the limits of wrong responses is not the same, and there is not just 1 interval of the wrong answers also. I would guess that for some other values here with 3 decimal places and ending with 5, there will be some other places where the results are wrong.

Using BigDecimal's rounding didn't help (but it returns different results - tested only on online JDK 8):
        java.math.MathContext c = new java.math.MathContext(4, java.math.RoundingMode.HALF_EVEN);

        for (int i = 10; i < 100; i++) {
            System.out.println(new java.math.BigDecimal(i + 0.915).round(c));
            System.out.println(new java.math.BigDecimal(i + 0.925).round(c));
        }


STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Execute the code from description - repeated here:

```
        java.text.DecimalFormat f = new java.text.DecimalFormat("0.00");
        System.out.println(f.getRoundingMode());

        for (int i = 0; i < 100; i++) {
            System.out.println(f.format(i + 0.915));
            System.out.println(f.format(i + 0.925));
        }
```

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
- rounding mode (default one): HALF_EVEN
- all number results ending with .92
ACTUAL -
HALF_EVEN
0.92
0.93
1.92
1.93
2.92
2.92
3.92
3.92
4.92
4.92
5.92
5.92
6.92
6.92
7.92
7.92
8.91
8.93
9.91
9.93
10.91
10.93
11.91
11.93
12.91
12.93
.....
56.91
56.92
57.91
57.92
58.91
58.92
59.91
59.92
60.91
60.92
61.91
61.92
62.91
62.92
63.91
63.92
64.92
64.92
65.92
65.92
66.92
66.92
67.92
67.92
68.92
68.92
69.92
69.92
70.92
70.92
71.92
71.92
72.92
72.92
73.92
73.92
74.92
74.92
75.92
75.92
....

FREQUENCY : always



Comments
Additional Information from submitter: =========================== Actually, this is fixed when using i.e. javax.money.NumberValue in my case. The issue is inside pebble mail templates which casts the object to java.lang.Number, and so returns wrongly rounded results. So, I'm guessing this one will be closed with Won't fix. Sorry.
02-11-2021

The binary representation of those X.915d and X.925d are between X.91499../X.91500.. and X.92499../X.92500... Thus rounding those numbers at the 3rd fraction digit produce in between X.91 and X.93. So this is the expected behavior.
28-10-2021

According the comment of https://bugs.openjdk.java.net/browse/JDK-8252892?focusedCommentId=14386648&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14386648 this issue is a duplicate of JDK-8252892.
28-10-2021