The OpenJDK Quality Group is promoting the testing of FOSS projects with OpenJDK builds as a way to improve the overall quality of the release. This heads-up is part of the quality outreach sent to the projects involved. To learn more about the program, and how-to join, please check here.

DecimalFormat Formats Floating-Point Values with the Double.toString(double) Algorithm

Since JDK 21, java.text.DecimalFormat::format and java.util.Formatter::toString produce slightly different outcomes on some double values, like the one from the snippet bellow.

double value = 7.3879E20;
int minFractionDigits = 0;

DecimalFormat df = (DecimalFormat) NumberFormat.getNumberInstance(Locale.ROOT);
df.setGroupingUsed(false);
df.setMinimumFractionDigits(minFractionDigits);
IO.println(df.format(value); // prints 738790000000000100000

Formatter fmt = new Formatter(Locale.ROOT);
fmt.format("%." + minFractionDigits + "f", value);
IO.println(fmt.toString()); // prints 738790000000000000000

This rare situation occurs because java.util.Formatter and Double.toString() use an algorithm enhanced in JDK 21. A fix was introduced in JDK 26 for the java.text.DecimalFormat implementation to use the same algorithm as java.util.Formatter and Double.toString(), thus producing the same outcome.

For a few releases, java.text.DecimalFormat will still offer the old algorithm to help migrate applications affected by this change. You can enable the old algorithm by appending -Djdk.compat.DecimalFormat=true to your java command; otherwise, the new algorithm runs.

Call to Action

We encourage you to download the JDK 26 Early Access builds, evaluate the behavior of your application and prepare to migrate if you see any impact. Feedback is also welcomed through the jdk-dev mailing list (registration required). For more details on this change, check the JBS issue JDK-8362448 and the release notes.