Integrated: JDK-8325898: ChoiceFormat returns erroneous result when formatting bad pattern

[Justin Lu]

On Thu, 15 Feb 2024 19:44:42 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which handles an edge case pattern bug with ChoiceFormat.
> 
> 
> var d = new ChoiceFormat("0#foo|1#bar|baz|") // creates cFmt equivalent to "0.0#foo|1.0#bar|1.0#"
> d.format(1) // unexpectedly returns ""
> 
> 
> Not only does this lead to faulty formatting results, but breaks the ChoiceFormat class invariant of duplicate limits.
> 
> It would have been preferable if either an exception was thrown when the ChoiceFormat was initially created, or the ChoiceFormat formatting 1 returned a value of "bar".
> 
> For comparison,
> 
> var d = new ChoiceFormat("0#foo|1#bar|baz") // creates cFmt equivalent to "0.0#foo|1.0#bar"
> d.format(1) // returns "bar"
> 
> 
> After this change, the first code snippet now returns "bar" when formatting 1 and discards the "baz" as the second code snippet does.
> 
> The fix prevents a limit/format entry from being built when the current parsing mode has not yet processed the limit and relation. The previous implementation would build an additional limit/format of 1 with an empty string. The `break` allows for the discarding of the incorrect portion and continuing. Alternatively an exception could have been thrown. For consistency with the second code snippet, the former was picked.
> 
> https://github.com/openjdk/jdk/pull/17856 may be of interest, which is a semi-related specification fix.

This pull request has now been integrated.

Changeset: d22d890c
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d22d890cac3c2c27f89445c65a91909c9cb8f9ad
Stats:     206 lines in 2 files changed: 94 ins; 91 del; 21 mod

8325898: ChoiceFormat returns erroneous result when formatting bad pattern

Reviewed-by: naoto

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

PR: https://git.openjdk.org/jdk/pull/17883