RFR: 6230751: [Fmt-Ch] Recursive MessageFormats in ChoiceFormats ignore indicated subformats [v2]
Justin Lu
jlu at openjdk.org
Fri Dec 1 22:14:20 UTC 2023
On Fri, 1 Dec 2023 21:51:14 GMT, Justin Lu <jlu at openjdk.org> wrote:
>> Please review this PR which updates an incorrect code example in _java/text/ChoiceFormat_.
>>
>> ChoiceFormat (and MessageFormat) provide an example of how to produce a pattern that supports singular and plural forms. The ChoiceFormat example is incorrect, as recursive MessageFormats produced by a ChoiceFormat subformat only recognize subformats defined through the MessageFormat pattern syntax, not through the subformats contained within the top level MessageFormat.
>>
>> In the original example,
>> `Format[] testFormats = {fileform, null, NumberFormat.getInstance()};` could have been replaced with
>> `Format[] testFormats = {fileform, null, new ChoiceFormat("0#BROKEN")};` and the original output would have been the same.
>>
>> This PR replaces the example with the one used in MessageFormat, which is correct.
>>
>> This PR also includes a drive-by fix to remove leftover `<blockquote>`s from a previous `@snippet` conversion.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>
> clarify limitations
src/java.base/share/classes/java/text/MessageFormat.java line 299:
> 297: * the string produced by a {@code ChoiceFormat} in {@code MessageFormat} is
> 298: * treated as special; occurrences of '{' are used to indicate subformats, and
> 299: * cause recursion. A limitation to this behavior is that, if a {@code MessageFormat}
@naotoj Please let me know if the added limitations wording reads clearly to you. I would rather not have a whole dedicated code example to explain a _limitation_, but if needed for better understanding, I can add one.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/16891#discussion_r1412604775
More information about the core-libs-dev
mailing list