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

Naoto Sato naoto at openjdk.org
Fri Aug 1 19:11:01 UTC 2025


On Fri, 1 Aug 2025 16:40:27 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   flipped again, which was correct
>
> src/java.base/share/classes/java/text/DecimalFormat.java line 422:
> 
>> 420:  * @implNote The default implementation follows the LDML specification for
>> 421:  * {@code parseLenient} elements to interpret minus sign patterns when lenient
>> 422:  * parsing is enabled.
> 
> IMO, the following is more clear.
> 
> `when lenient parsing is enabled` -> `when {@link #isStrict()} returns false`
> `interpret minus sign patterns` -> `enable loose matching of minus sign patterns`
> 
> Also, I'm unsure on mentioning `{@code parseLenient} elements` because I'm not sure that users of DecimalFormat will be aware of such LMDL elements. This also seems to be the first time a direct mention of an LDML element is made. I'm not sure of a better alternative ATM.

Thanks, modified as you suggested. For the `parseLenient`, the problem is in the LDML document side, as there is no description for it, and their loose matching description is kind of incorrect (use [:DASH:], which is not the case here. So I just dropped it in this iteration.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26580#discussion_r2248692643


More information about the i18n-dev mailing list