On Tue, 1 Apr 2025 18:17:12 GMT, Naoto Sato <[email protected]> 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
