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

Justin Lu jlu at openjdk.org
Fri Aug 1 16:42:56 UTC 2025


On Thu, 31 Jul 2025 22:30:35 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Enabling lenient minus sign matching when parsing numbers. In some locales, e.g. Finnish, the default minus sign is the Unicode "Minus Sign" (U+2212), which is not the "Hyphen Minus" (U+002D) that users type in from keyboard. Thus the parsing of user input numbers may fail. This change utilizes CLDR's `parseLenient` element for minus signs and loosely matches them with the hyphen-minus so that user input numbers can parse. As this is a behavioral change, a corresponding CSR has been drafted.
>
> 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.

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

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


More information about the i18n-dev mailing list