<i18n dev> RFR: 8353322: Specification of ChoiceFormat#parse(String, ParsePosition) is inadequate [v2]

[Naoto Sato]

On Tue, 1 Apr 2025 19:04:25 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which specifies the `ChoiceFormat#parse(String, ParsePosition)` method. A corresponding CSR is filed. The current specification is simply "Parses a Number from the input text" which does not indicate how the value is returned. The criteria for a match, as well as no match should be made clear.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reflect Naoto's review

I am OK with returning `Double.NaN` as normative. I believe the risk is quite low, and it would be only a conformance issue (no practical problem will arise)

src/java.base/share/classes/java/text/ChoiceFormat.java line 564:

> 562:      * {@code Double}. The value returned is the {@code limit} corresponding
> 563:      * to the {@code format} that is the longest substring of the input text.
> 564:      * Matching is done in ascending order, when multiple {@code formats} match

Nit: {@code format}s

src/java.base/share/classes/java/text/ChoiceFormat.java line 584:

> 582:      * first index of the character that caused the parse to fail.
> 583:      * @return A Number which represents the {@code limit} corresponding to the {@code
> 584:      * format} parsed.

We could clarify the no match case with `Double.NaN` here too

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

PR Review: https://git.openjdk.org/jdk/pull/24361#pullrequestreview-2733870693
PR Review Comment: https://git.openjdk.org/jdk/pull/24361#discussion_r2023570395
PR Review Comment: https://git.openjdk.org/jdk/pull/24361#discussion_r2023571566