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

[Justin Lu]

On Tue, 1 Apr 2025 18:17:12 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   reflect Naoto's review
>
> 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).

I was either way on the `implNote`, since I thought an implementation could decide to normalize a double limit to an integral type. However that's probably unlikely and I agree the wording can be fine as normative since ChoiceFormat is composed of doubles.

I think it's best to make returning Double.NaN normative (i.e. not allow flexibility for throwing an exception). The `NumberFormat.parse(String, ParsePosition)` methods return a failure value instead of throwing like `parse(String)` does. (E.g. DecimalFormat returns null on failed parse for 2 arg parse.)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24361#discussion_r2023523992