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

[weigao]

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/db779800/attachment.htm>