Summary

Correct DecimalFormat’s implementation to handle an edge case when formatting a fractional floating-point value would return a zero string, violating the UP, CEILING, and FLOOR RoundingMode contracts.

Problem

DecimalFormat, when formatting a floating-point value, will first make a conversion from a floating-point value to a string representation, (from here on, out referred to as s). s is then truncated and rounded under the DecimalFormat pattern and RoundingMode to create the resultant string returned.

In this particular edge case, if the maximum fractional digits given by the DecimalFormat pattern is less than the amount of leading zeroes in the fractional portion of s, DecimalFormat incorrectly returned a zero string, instead of considering rounding. By not considering rounding, formatting certain floating-point values violated the UP, CEILING, and FLOOR RoundingMode contracts. Specifically, the stipulation: "Note that this rounding mode never decreases the magnitude of the calculated value".

For example, consider a DecimalFormat with pattern “0.0” and RoundingMode.UP which formats the numerical value .001. This numerical value, which is a representation of the floating-point value 0.001000000000000000020816681711721685132943093776702880859375 is converted to the decimal string “0.001” by DecimalFormat. The existing implementation assumes it can return zero as the fractional precision (1) given by the DecimalFormat pattern is less than the count of fractional leading zeros (2) in the decimal string. However, returning the formatted string "0.0" violates the RoundingMode.UP contract and should have been "0.1".

Solution

Ensure that rounding is considered, even if the maximum fractional digits allowed by the DecimalFormat pattern is less than the leading fractional zeroes given by s for formatting a fractional floating-point value.

Given the double value 0.00010000000000000000479217... represented by the numerical value 0.0001, the following is an example of the behavioral changes under every RoundingMode with a "0.00" pattern DecimalFormat. Unless marked as different, the results are the same as before the change.

0.0001 formatted with 0.00 and mode UP gives 0.01 (previously, 0.00)
0.0001 formatted with 0.00 and mode DOWN gives 0.00
0.0001 formatted with 0.00 and mode CEILING gives 0.01 (previously, 0.00)
0.0001 formatted with 0.00 and mode FLOOR gives 0.00
0.0001 formatted with 0.00 and mode HALF_UP gives 0.00
0.0001 formatted with 0.00 and mode HALF_DOWN gives 0.00
0.0001 formatted with 0.00 and mode HALF_EVEN gives 0.00
-0.0001 formatted with 0.00 and mode UP gives -0.01 (previously, -0.00)
-0.0001 formatted with 0.00 and mode DOWN gives -0.00
-0.0001 formatted with 0.00 and mode CEILING gives -0.00
-0.0001 formatted with 0.00 and mode FLOOR gives -0.01 (previously, -0.00)
-0.0001 formatted with 0.00 and mode HALF_UP gives -0.00
-0.0001 formatted with 0.00 and mode HALF_DOWN gives -0.00
-0.0001 formatted with 0.00 and mode HALF_EVEN gives -0.00 

Note: This change does not affect the case where the DecimalFormat maximum fractional digits is equivalent to the leading fractional zeroes given by s. Rounding behavior for that case remains the same. For example, the double value 0.0500000000000000027755... given by the numerical value 0.05 would still format to 0.1 under a "0.0" DecimalFormat pattern with HALF_UP. (This behavior correctly occurs before and after this change).

Specification

N/A (behavioral change only)