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

[weigao]

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> 于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/64412c81/attachment-0001.htm>