<i18n dev> RFR: 8363972: Loose matching of dash/minusSign in number parsing [v7]

[Naoto Sato]

On Tue, 5 Aug 2025 16:53:06 GMT, Justin Lu <jlu at 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