On Mon, 20 Jul 2026 23:12:18 GMT, Justin Lu <[email protected]> wrote:
> This PR corrects two parsing issues for `DecimalFormat` during strict parsing. > > 1. The special parsing path for NaN was shared by lenient and strict > parsing. As a result, subsequent text after the "NaN" was accepted in strict > mode, although the trailing characters should have caused parsing to fail. > Strict parsing needs to add additional logic for that special case. > > 2. In strict mode, a grouping size of zero causes all numeric input to be > rejected since it tries to check for the first group immediately. A grouping > size of zero is implies that grouping is not used. However, `isGroupingUsed` > is independent of `setGroupingSize`. The implementation needs to check for > both the int size and boolean status value when checking grouping during > strict parsing. > > --------- > - [x] I confirm that I make this contribution in accordance with the [OpenJDK > Interim AI Policy](https://openjdk.org/legal/ai). src/java.base/share/classes/java/text/DecimalFormat.java line 2765: > 2763: return isGroupingUsed() && groupingSize > 0; > 2764: } > 2765: "Relevant" sounds a bit vague here. Since this checks whether grouping is effectively enabled (`isGroupingUsed()` and a positive grouping size), how about `isGroupingEnabled()`? Also, I think you meant "lenient" instead of "legacy" at the last comment line. test/jdk/java/text/Format/NumberFormat/StrictParseTest.java line 127: > 125: fmt.setGroupingUsed(true); > 126: var pp = new ParsePosition(0); > 127: assertThrows(ParseException.class, () -> fmt.parse("555,000.0", > pp)); I ran this locally and it seems failing. `parse` returns `null` instead of throwing the exception ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/31980#discussion_r3624302126 PR Review Comment: https://git.openjdk.org/jdk/pull/31980#discussion_r3624433057
