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 bynf.format(0.8055d)
, value0.8055d
is recorded in the computer as0.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