RFR: 8353322: Specification of ChoiceFormat#parse(String, ParsePosition) is inadequate

Naoto Sato naoto at openjdk.org
Tue Apr 1 18:22:15 UTC 2025


On Tue, 1 Apr 2025 16:45:26 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.

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


More information about the core-libs-dev mailing list