On Tue, 1 Apr 2025 16:45:26 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.
src/java.base/share/classes/java/text/ChoiceFormat.java line 571:
> 569: * {@snippet lang=java :
> 570: * var fmt = new ChoiceFormat("0#foo|1#bar|2#baz");
> 571: * fmt.parse("baz", new ParsePosition(0)); // returns 2
This returns `2.0`?
src/java.base/share/classes/java/text/ChoiceFormat.java line 576:
> 574: *
> 575: * @implNote The {@code Number} subtype returned by the JDK reference
> 576: * implementation of this method is always {@code Double}.
Do we need to use `@implNote` here? Since choices are `double`s (as in the
class description), I think we can safely say this returns a `Double` as in
normative text. If some implementation returns an `Integer`, I think it is a
bug. Returning a `Double.NaN` for no-match may be considered implNote though
(one might throw an exception).
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/24361#discussion_r2023404649
PR Review Comment: https://git.openjdk.org/jdk/pull/24361#discussion_r2023462230
