On Tue, 1 Apr 2025 19:04:25 GMT, Justin Lu <[email protected]> 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
