test for issue #4917

[pjfanning]

test case for #4917

[dbachdev]

so far does not seem to reproduce the claimed bug in #4917

could you please add: assertEquals(50, issue.number); ?

[pjfanning]

@cowtowncoder this test case does reproduce the issue for the double. It gets the wrong value - it gets the value from the decimal field instead.

So far, it seems like the issue was introduced in v2.15 - probably v2.15.0.

Unfortunately 2.15.0 has a lot of changes and it would seem that one of changes to bring in the lazy evaluation of numbers is the cause of this issue.

[pjfanning]

@cowtowncoder FasterXML/jackson-core#1389 seems to fix this

[pjfanning]

@cowtowncoder FasterXML/jackson-core#1389 has a test where I reproduced the issue

Maybe we could get 1389 and this merged to the 2.19 branches and backfit to jackson 2.18 and 2.17 (maybe 2.16)?

The issue is not related to TokenBuffer and appears to be related to using getNumberType call on the parser and then not using a call to get the number - which leaves behind a non-nulled _numberString value. When the next number is an int (in the JSON), the code does not update the _numberString and maintains the _numberInt directly but some code paths can then go back to _numberString despite it being for an earlier number.