JDK-8362448 : Make use of the Double.toString(double) algorithm in java.text.DecimalFormat
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.text
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2025-07-16
  • Updated: 2025-08-18
  • Resolved: 2025-08-18
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 26
26 masterFixed
Related Reports
CSR :  
Relates :  
Relates :  
Relates :  
Sub Tasks
JDK-8365690 :  
Description
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.
Comments
Changeset: 285adff2 Branch: master Author: Raffaello Giulietti <rgiulietti@openjdk.org> Date: 2025-08-18 16:12:34 +0000 URL: https://git.openjdk.org/jdk/commit/285adff24e869b62397d4d1c14e6e969f3285836
18-08-2025

In the release note, I think we will also want to mention the NumberFormat factory methods to some degree. This implementation's default LocaleServiceProvider always provides a DecimalFormat or CompactNumberFormat, but that may not be immediately clear to users (since those methods abstract the return type to NumberFormat). In fact, the majority of DecimalFormat users are probably using them via the localized factory methods.
17-07-2025

A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk/pull/26364 Date: 2025-07-17 10:04:10 +0000
17-07-2025