Deserialization improvements

[dstepanov]

Refactoring/rewriting of the deserialization:

• Detection of the subtype is extracted to a separate deserializer with a newly introduced lookahead deserializer
• SpecificObjectDeserializer rewritten to avoid buffering and to simplify the code

[yawkat]

i dont like the LookaheadDecoder abstraction. I will try to find an alternative.

[dstepanov]

Ok

[yawkat]

@dstepanov take a look. This approach avoids new API on Decoder, and it uses the existing decodeBuffer so in theory the jackson implementation can be based on TokenBuffer for performance at some point.

Also do you think the changes to JsonNodeDecoder still have value now that the new subtypes are gone? If not, we can revert them for easier review

[dstepanov]

I did a bit of benchmarking of the unwrapped scenario: 10% faster than the previous code.

Vs Jackson:

Benchmark                                                (stack)  Mode  Cnt    Score    Error  Units
JacksonBenchmark.decodeUnwrapped  JACKSON_DATABIND_INTROSPECTION  avgt   10  660.406 ± 11.924  ns/op
JacksonBenchmark.decodeUnwrapped                   SERDE_JACKSON  avgt   10  554.094 ±  7.019  ns/op

[dstepanov]

@yawkat Looks fine. I think there are some improvements added to JsonNodeDecoder, you can copy those subclasses back into the decoder if you want.

[dstepanov]

@yawkat Can this be rewritten using an iterator?

[yawkat]

no because the list may change size

[dstepanov]

@yawkat IMHO it would be better if DemuxingObjectDecoder was split into two implementations, one that caches and one that replays / delegates. Now it's hard to understand with all the states there.

[yawkat]

Do you mean just moving the nested classes or actually weakening the API?

[dstepanov]

The best would be to have two implementation, the state can be passed as a map of string -> decoder

[yawkat]

that'd be less powerful though, e.g. right now you can do more than two "passes", reading more properties each time. it would also not allow for concurrent reading though im not sure if that's useful.

but it'd also have a worse performance impact, right now if the first reader does finishStructure(true) the remaining properties are left undecoded and the second reader can access them without buffering. that cant be done if you wrap the full state in a Map.

[dstepanov]

Ok let's keep it this way.

[sonarqubecloud]

SonarCloud Quality Gate failed.   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
15 Code Smells

75.9% Coverage
1.1% Duplication

Catch issues before they fail your Quality Gate with our IDE extension SonarLint