Is inconsistency in rounding between Java 7 and Java 8 a bug?

It looks like this was a long-standing bug in JDK 7 that was finally fixed. See for example:

There is a draft plan to provide the following advisory with JDK 8 which explains the issue:

——————————————————————— Area: Core Libraries / java.text

Synopsis: A wrong rounding behavior of JDK7 has been fixed. The
rounding behavior of NumberFormat/DecimalFormat format() method has
changed when value is very close to a tie sitting exactly at the
rounding position specified in the formatting pattern.

Nature of Incompatibility: behavioral

Description: When using NumberFormat/DecimalFormat classes, the
rounding behavior of previous JDK versions was wrong in some corner
cases. This wrong behaviour happened when calling format() method with
a value that is very close to a tie, while rounding position specified
by the pattern of the NumberFormat/DecimalFormat instance used is
exactly sitting at the position of the tie. In that case wrong double
rounding or erroneous non-rounding behavior happened.

As an example, while using default recommended NumberFormatFormat API
form: NumberFormat nf = java.text.NumberFormat.getInstance() followed
by nf.format(0.8055d), value 0.8055d is recorded in the computer as
0.80549999999999999378275106209912337362766265869140625 since this value cannot be represented exactly in binary format. Here default
rounding rule is “half-even”, and the result of calling format() in
JDK7 is a wrong output of “0.806”, while correct result is “0.805”
since value recorded in memory by the computer is “below” the tie.

This new behavior is also implemented for all rounding positions
that might be defined by any pattern chosen by the programmer (non
default ones).

RFE
7131459


Leave a Comment