On Tue, 5 Aug 2025 16:53:06 GMT, Justin Lu <j...@openjdk.org> wrote:
>> Naoto Sato has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> refrects review comments
>
> src/java.base/share/classes/java/text/DecimalFormatSymbols.java line 719:
>
>> 717:
>> 718: /**
>> 719: * {@return the lenient minus signs} Multiple lenient minus signs
>
> Do we have an idea of when a given locale would not have access to the
> lenient minus signs provided by parseLenient element? If the vast majority of
> times it will, then it is fine. Otherwise IMO, `getLenientMinusSigns()`
> should probably call out the fact that it may not always be a concatenation
> of multiple minus _signs_, and it may be a single minus _sign_ (as assigned
> by `minusSignText`). Since that detail is only apparent by digging around the
> code that assigns `lenientMinusSigns`.
The lenient minus signs are embedded in number elements for the Laitn script
(latn.NumberElements), so they are mostly in each locale data.
> src/java.base/share/classes/java/text/DecimalFormatSymbols.java line 852:
>
>> 850:
>> 851: // Lenient minus signs
>> 852: lenientMinusSigns = numberElements.length < 14 ? minusSignText
>> : numberElements[13];
>
> BTW, if I remove this check and always assign to `numberElements[13]`, I do
> not observe any failures in the java_text/Format suite. It would be nice to
> have an idea of why this check is needed. (I understand it is following the
> same length checks of monetarySeparator and monetaryGroupingSeparator.)
The FALLBACK locale provider does not provide those elements, so the check is
needed. Some tests in java/sun.util tests that specify HOST provider would fail
without it.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/26580#discussion_r2255492762
PR Review Comment: https://git.openjdk.org/jdk/pull/26580#discussion_r2255492528
