Currently, DecimalFormat sometimes outputs `double`s with more digits than the equivalent outputs of Formatter, or with slightly different digits.
For example, the `double` 7.3879E20 is output as "738790000000000100000" with DecimalFormat and as "738790000000000000000" with Formatter, given equivalent format specifications.
Since JDK 21, Double.toString() and Formatter use a new double->string algorithm, while DecimalFormat still uses the original double->string algorithm from older releases.
The consequence is that the outcomes of DecimalFormat and Formatter may differ even with equivalent format specifications.
While this mismatch rarely happens in practice (the vast majority of doubles work just fine), it is preferable to align DecimalFormat with Formatter, and make use of the new double->string algorithm introduced in JDK 21 in DecimalFormat as well.
For example, the `double` 7.3879E20 is output as "738790000000000100000" with DecimalFormat and as "738790000000000000000" with Formatter, given equivalent format specifications.
Since JDK 21, Double.toString() and Formatter use a new double->string algorithm, while DecimalFormat still uses the original double->string algorithm from older releases.
The consequence is that the outcomes of DecimalFormat and Formatter may differ even with equivalent format specifications.
While this mismatch rarely happens in practice (the vast majority of doubles work just fine), it is preferable to align DecimalFormat with Formatter, and make use of the new double->string algorithm introduced in JDK 21 in DecimalFormat as well.
- csr for
-
JDK-8362612 Make use of the Double.toString(double) algorithm in java.text.DecimalFormat
-
- Finalized
-
- relates to
-
JDK-8300869 Make use of the Double.toString(double) algorithm in java.util.Formatter
-
- Closed
-
-
JDK-4511638 Double.toString(double) sometimes produces incorrect results
-
- Resolved
-
- links to
-
Review(master) openjdk/jdk/26364