-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support in TokenBuffer
for lazily decoded (big) numbers
#3730
Comments
@cowtowncoder I added lazy nums in #3727 In the test case that shows the unnecessary parseBigInteger call now doesn't end up parsing the big int - the LazyBigInteger is stored but the number is never parsed. Unfortunately, not many existing tests lead to lazy nums being actually parsed - so I can't yet guarantee that the lazy code actually works all the way through. |
Another potential mechanism to use: FasterXML/jackson-core#902 (assuming I get to implement it). EDIT: Ok it was easier than I thought;
ready for review. |
Ok, instead I went with: with adds One thing I need to figure out has to do with testing, how to verify expected handling improvements both wrt skipping of unused contents (need mocking, maybe?) and wrt retaining of exact representation through buffering. |
@cowtowncoder #3761 is open |
Merged #3761 so this is now implemented. |
(note: for background see #3721)
There are a few issues with
TokenBuffer
regarding number coercions, mostly due to eager buffering sometimes needed, which forces decision on use of type (double
vsBigDecimal
in particular) before knowing target type.There are also concerns about overhead in some cases, preventing efficient skipping of big number values in cases where buffering is needed: for example, when
@JsonCreator
use requires preservation of content that would ultimately be skipped.An idea that came to mind is that since
TokenBuffer
stores all buffered content using 2 elements --JsonToken
for type, and opaqueObject
(depending on type) -- it would be possible to augment handling to use hypotheticalBufferedNumber
(orLazyNumber
) type, which could:NumberType
(to preserve distinction between finer grainJsonParser
exposes)BigInteger
, all floating-point types)This would require support from
jackson-core
for:BufferedNumber
) as well as implementation(s) if not concreteJsonParser
-- either specific "always get buffered" or hybrid (buffered if not decoded;Number
if decoded)There are probably other subtleties too but this is the general idea. If anyone plans to work on this, another issue needs to be created on
jackson-core
side.The text was updated successfully, but these errors were encountered: