[wenshao]

• Use bit-shift operations for faster digit parsing
• Simplify overflow detection to single check after digit loop
• Handle exponent with combined scale to avoid string-based parsing

What this PR does / why we need it?

Summary of your change

Please indicate you've done the following:

• Made sure tests are passing and test coverage is added if needed.
• Made sure commit message follow the rule of Conventional Commits specification.
• Considered the docs impact and opened a new docs issue or PR with docs changes if needed.

[wenshao]

The same overflow check is duplicated in core/src/main/java/com/alibaba/fastjson2/JSONReaderUTF16.java and should be fixed there as well.

— gpt-5.5 via Qwen Code /review

[wenshao]

[Critical] This post-loop overflow check can accept corrupted 19-digit values. For exactly 19 digits, values greater than Long.MAX_VALUE may overflow during longValue = longValue * 10 + digit and still finish with a non-negative wrapped longValue, so they take the BigDecimal.valueOf(longValue, combinedScale) fast path instead of falling back to TypeUtils.parseBigDecimal(...). That can silently return the wrong BigDecimal for valid JSON numbers outside signed long range.

A safer fix is to restore per-digit overflow detection, or add an exact 19-digit range check before using the accumulated longValue; otherwise force the existing string-based fallback.

— gpt-5.5 via Qwen Code /review

[wenshao]

Reviewed. Suggestions are inline.

— qwen3.8-max-preview via Qwen Code /review

[wenshao]

[Suggestion] The comment misdescribes the overflow condition — it reads as "more than 18 digits" is sufficient for overflow, but the code only flags overflow unconditionally at 20+ digits; 19 digits overflows only when the sign bit is set. — Concrete cost: a maintainer trusting the comment could simplify to digitCount > 18, forcing every valid 19-digit long (e.g. Long.MAX_VALUE) onto the slow TypeUtils.parseBigDecimal path — a silent performance regression.

Suggested change

	// Check overflow: more than 18 digits, or 19 digits with negative value (sign bit set)
	boolean overflow = digitCount > 18 && (digitCount > 19 || longValue < 0);
	// Check overflow: 20+ digits always overflow; exactly 19 digits overflow only if sign bit is set
	boolean overflow = digitCount > 18 && (digitCount > 19 || longValue < 0);

— qwen3.8-max-preview via Qwen Code /review

[wenshao]

[Suggestion] Same misleading comment as in JSONReaderUTF16.java — it reads as "more than 18 digits" is sufficient for overflow, but the code only flags overflow unconditionally at 20+ digits; 19 digits overflows only when the sign bit is set. — Concrete cost: a maintainer trusting the comment could simplify to digitCount > 18, forcing every valid 19-digit long onto the slow path.

Suggested change

	// Check overflow: more than 18 digits, or 19 digits with negative value (sign bit set)
	boolean overflow = digitCount > 18 && (digitCount > 19 || longValue < 0);
	// Check overflow: 20+ digits always overflow; exactly 19 digits overflow only if sign bit is set
	boolean overflow = digitCount > 18 && (digitCount > 19 || longValue < 0);

— qwen3.8-max-preview via Qwen Code /review

[wenshao]

[Suggestion] The new exponent fast path in JSONReaderUTF8.readBigDecimal() has no test asserting the exact BigDecimal result (value and scale) from byte[] input with exponent notation. The only UTF8 test with exponents (DoubleTest.parseDouble1, input "123.123E256") asserts only .doubleValue(), discarding scale. — Concrete cost: a future scale error in the UTF8 path that preserves the double value would go undetected. The UTF16 path is covered by Issue492 with exact BigDecimal assertions.

Consider adding a test that parses exponent-notation numbers from byte[] and asserts exact BigDecimal equality (e.g. assertEquals(new BigDecimal("1.1111111E7"), JSON.parseObject(bytes, BigDecimal.class))), mirroring Issue492's coverage.

— qwen3.8-max-preview via Qwen Code /review