[External] Feedback JDK-8318761 : Potential Issue in JDK 25 MessageFormat: Use of Internal Exception for Control Flow

[Chen Liang]

Hello Vincent Gao,
I saw your Java Bugs submission. Unfortunately your stacktrace caused some confusion to our triage because it is an internal exception and that trace is never printed anywhere.
Your suggestion is a reasonable enhancement, that we should not use ad-hoc exceptions for control flow, given they need to fill stack traces, which is extremely costly.
Since this is a cleanup, we might commit this to mainline JDK first. If this proves to be a performance bottleneck on 25 updates, we can backport.
Since you are writing here, I assume this has a non-negligible impact on performance.
If you can share a flame graph showing the regression from this exception, or a benchmark difference between 21 and 25.0.1, this would be extremely helpful.

Regards,
Chen Liang
________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of weigao <china.weigao at gmail.com>
Sent: Wednesday, December 10, 2025 9:31 PM
To: core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
Subject: Re: [External] Feedback JDK-8318761 : Potential Issue in JDK 25 MessageFormat: Use of Internal Exception for Control Flow

hi , because of ``private static FormatStyle fromString(String text)` throw exception and the try catch exception just set the deault value `FormatStyle.SUBFORMATPATTERN`  , so why just make this function retuen this value like ? Is it better , right  ?
```

private static FormatStyle fromString(String text) {
    for (FormatStyle style : values()) {
        // Also check trimmed case-insensitive for historical reasons
        if (style != FormatStyle.SUBFORMATPATTERN &&
                text.trim().compareToIgnoreCase(style.text) == 0) {
            return style;
        }
    }
    return FormatStyle.SUBFORMATPATTERN;
}

```

weigao <china.weigao at gmail.com<mailto:china.weigao at gmail.com>> 于2025年12月11日周四 11:21写道：

Hello,

I would like to report a potential design issue in the JDK 25 implementation of MessageFormat.

While working with java.util.Locale#getDisplayName(), I found that JDK internals throw and catch an IllegalArgumentException due to the following pattern added in the resource bundles:

  *   sun.util.resources.cldr.LocaleNames

  *   sun.util.resources.LocaleNames

The pattern in question is:

DisplayNamePattern: {0,choice,0#|1#{1}|2#{1} ({2})}


This change originates from the following commit:
adoptium/jdk at 00ffc42 ― which adds a pattern for MessageFormat.
However, choice is not a valid type for FormatStyle.

As a result, calling Locale#getDisplayName() triggers the following exception inside JDK code:

java.lang.IllegalArgumentException
    at java.base/java.text.MessageFormat$FormatStyle.fromString(MessageFormat.java:2013)
    at java.base/java.text.MessageFormat.formatFromPattern(MessageFormat.java:1718)
    at java.base/java.text.MessageFormat.setFormatFromPattern(MessageFormat.java:1679)
    at java.base/java.text.MessageFormat.applyPatternImpl(MessageFormat.java:660)
    at java.base/java.text.MessageFormat.<init>(MessageFormat.java:516)
    at java.base/java.util.Locale.getDisplayName(Locale.java:2309)


The implementation currently relies on exception-based logic:

try {
    fStyle = FormatStyle.fromString(style);
} catch (IllegalArgumentException iae) {
    fStyle = FormatStyle.SUBFORMATPATTERN;
}


I understand that MessageFormat catches this exception and falls back to SUBFORMATPATTERN, but using exceptions to control expected logic paths may not be ideal―especially since FormatStyle.fromString() is only used by MessageFormat.

A potentially cleaner approach could be to have FormatStyle.fromString() return FormatStyle.SUBFORMATPATTERN directly when encountering unknown style identifiers, instead of throwing an exception.

JDK Version Observed:

OpenJDK Runtime Environment Temurin-25.0.1+8 (build 25.0.1+8-LTS)


Please let me know if this behavior is intentional, or if it should be considered for improvement.

Best regards,
vincent gao
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20251211/484dd06c/attachment-0001.htm>