Preserve explicit "+" sign across buffer boundaries for "+0..." on async parser#1614
Merged
cowtowncoder merged 3 commits intoMay 27, 2026
Merged
Conversation
…arser
The non-blocking parser reused MINOR_NUMBER_ZERO for both bare-zero ("0...")
and explicit-plus-zero ("+0...") suspension paths, so the leading '+' was
lost when input arrived byte-by-byte. Add a dedicated MINOR_NUMBER_PLUSZERO
state alongside MINOR_NUMBER_ZERO/MINOR_NUMBER_MINUSZERO;
_finishNumberLeadingPosNegZeroes now stores MINOR_NUMBER_PLUSZERO when
negative=false, restoring symmetry with the blocking parsers and the sibling
"+123" path.
Update AsyncNonStandardNumberParsingTest#leadingPlusSignInDecimalEnabled2
to assert "+0.123" -- the previous "0.123" assertion contradicted the
sibling test for "+123" and was masked by the bug.
Noticed while working on hex-literal support (FasterXML#707); split out per
maintainer request.
seonwooj0810
added a commit
to seonwooj0810/jackson-core
that referenced
this pull request
May 27, 2026
The async-parser '+0...' resumption fix is being split out into PR FasterXML#1614. This commit renumbers MINOR_NUMBER_PLUSZERO from 35 to 33 (and shifts the hex constants to 34/35) so feat/707 matches whatever the split PR lands as in 3.x -- avoiding a numeric collision when 3.x is merged back in. Also drops the leftover [core#707] tag from the PLUSZERO comment now that the primitive lives in its own PR; the comment in NonBlockingUtf8 is reformatted for the same reason.
3 tasks
Member
|
Nice clean split — easy to review in isolation. One small thing worth calling out in the PR description (not a blocker):
|
Contributor
📈 Overall Code Coverage
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Splits out the drive-by async-parser fix from #1613 per @cowtowncoder's request, so the hex feature PR can stay focused.
The non-blocking parser reused
MINOR_NUMBER_ZEROfor both the bare-zero (0…) and explicit-plus-zero (+0…) suspension paths, so the leading+was lost when input arrived byte-by-byte. The sibling tests inAsyncNonStandardNumberParsingTestalready disagreed with each other:leadingPlusSignInDecimalEnabled(+123) — asserted"+123"✅leadingPlusSignInDecimalEnabled2(+0.123) — asserted"0.123"❌ (lost the+)This change adds a dedicated
MINOR_NUMBER_PLUSZEROstate alongsideMINOR_NUMBER_ZERO/MINOR_NUMBER_MINUSZERO._finishNumberLeadingPosNegZeroesnow storesMINOR_NUMBER_PLUSZEROwhennegative=false, so the buffered text on resume retains the leading+, matching the blocking parsers and the sibling+123path.AsyncNonStandardNumberParsingTest#leadingPlusSignInDecimalEnabled2is updated to assert the now-preserved"+0.123"output. The previous"0.123"assertion was masked by the bug.Background
Discovered while implementing the JSON5 hex feature (#1613) — async tests with 1-byte feeds surfaced the divergence. Per maintainer comment ("yes, please, that'd be worth fixing separately, can merge quickly"), splitting it out here. Unrelated to the hex feature itself, so easy to review in isolation.
Test plan
mvn test— 1675 tests, 0 failures, 0 regressions (2 pre-existing skips).AsyncNonStandardNumberParsingTest— 18 tests pass, including the updatedleadingPlusSignInDecimalEnabled2.Notes