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