JDK-8062013 : DecimalFormat / rounding / HALF_UP
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.text
  • Affected Version: 8u25
  • Priority: P3
  • Status: Resolved
  • Resolution: Not an Issue
  • OS: windows_7
  • CPU: x86_64
  • Submitted: 2014-10-23
  • Updated: 2014-10-28
  • Resolved: 2014-10-27
Related Reports
Duplicate :  
Relates :  
Description
FULL PRODUCT VERSION :
java version "1.8.0_25"
Java(TM) SE Runtime Environment (build 1.8.0_25-b18)
Java HotSpot(TM) 64-Bit Server VM (build 25.25-b02, mixed mode)

ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows [Version 6.1.7601]

A DESCRIPTION OF THE PROBLEM :
Problem with rounding up:

DecimalFormat l_format = new DecimalFormat();

l_format.setRoundingMode(RoundingMode.HALF_UP);
l_format.setMaximumFractionDigits(2);
l_format.getDecimalFormatSymbols().setDecimalSeparator('.');

System.out.println(l_format.format(13.135d));

With 2 fraction digits I think the output must be 13.14, but it is 13.13 even after the fix for Bug-ID: 8039915 (applied in the boot class path with the jdk8-dev sources). 

REGRESSION.  Last worked in version 7u72

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Just execute the code written in the description.


REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
DecimalFormat l_format = new DecimalFormat();

l_format.setRoundingMode(RoundingMode.HALF_UP);
l_format.setMaximumFractionDigits(2);
l_format.getDecimalFormatSymbols().setDecimalSeparator('.');

assertEquals(13.14d, l_format.format(13.135d));
---------- END SOURCE ----------


Comments
Here is a short program that shows the returned result is correct: DecimalFormat l_format = new DecimalFormat(); l_format.setRoundingMode(RoundingMode.HALF_UP); l_format.setMaximumFractionDigits(2); l_format.getDecimalFormatSymbols().setDecimalSeparator('.'); System.out.println("BigDecimal output for 13.135 -> " + new BigDecimal(13.135d).toString()); System.out.println("NumberFormatFormat.format() output for 13.135 -> " + l_format.format(13.135d) + "\n"); When suspecting a bug in this package, please use BigDecimal class to check the binary representation of the value in the machine
27-10-2014

This is another false positive. Closest binary approximation of 13.135d is 13.1349999999999997868371792719699442386627197265625. It is thus below the tie. Thus returned result 13.13 is correct and is the one expected.
27-10-2014