Jackson ByteBufferFeeder support #1711
Comments
daschl
added a commit
to daschl/servicetalk
that referenced
this issue
Nov 5, 2022
Motivation: In 2.14.0, Jackson added support for feeding ByteBuffers directly into the streaming parser engine (where previously only byte arrays would be supported). This changeset incorporates this enhancement into the JacksonStreamingSerializer infrastructure. Modifications: Before this changeset, the ByteArrayParser (and corresponding feeder) were the only choice when using the streaming deserialization infrastructure in Jackson, so the code was able to eaglerly initialize the parser and feeder. Now there is a choice that can be made at runtime which parser might be the best one based on the incoming buffer in the stream. As such, the code now checks the first Buffer and then decides if either the array-backed or the bytebuffer-backed parser should be initalized. This also has the advantage that if no items are emitted on an empty stream, no parser needs to be initialized at all. Note that the code still preserves the runtime "backed by type" checks since (while likely not common but possible) buffers with different backing types can arrive one after another and need to be handled. In this case it is possible that a sub-optimal parser is chosen, but the code optimizes for the likely scenario that all buffers on one stream are backed by the same type. Result: Added support for Jackson's new ByteBufferFeeder and choosing the best strategy at runtime depending on the first buffer type that arrives.
|
related to: FasterXML/jackson-core#795 |
daschl
added a commit
to daschl/servicetalk
that referenced
this issue
Nov 16, 2022
Motivation: In 2.14.0, Jackson added support for feeding ByteBuffers directly into the streaming parser engine (where previously only byte arrays would be supported). This changeset incorporates this enhancement into the JacksonStreamingSerializer infrastructure. Modifications: Before this changeset, the ByteArrayParser (and corresponding feeder) were the only choice when using the streaming deserialization infrastructure in Jackson, so the code was able to eaglerly initialize the parser and feeder. Now there is a choice that can be made at runtime which parser might be the best one based on the incoming buffer in the stream. As such, the code now checks the first Buffer and then decides if either the array-backed or the bytebuffer-backed parser should be initalized. This also has the advantage that if no items are emitted on an empty stream, no parser needs to be initialized at all. Note that the code still preserves the runtime "backed by type" checks since (while likely not common but possible) buffers with different backing types can arrive one after another and need to be handled. In this case it is possible that a sub-optimal parser is chosen, but the code optimizes for the likely scenario that all buffers on one stream are backed by the same type. Result: Added support for Jackson's new ByteBufferFeeder and choosing the best strategy at runtime depending on the first buffer type that arrives.
daschl
added a commit
to daschl/servicetalk
that referenced
this issue
Nov 16, 2022
Motivation: In 2.14.0, Jackson added support for feeding ByteBuffers directly into the streaming parser engine (where previously only byte arrays would be supported). This changeset incorporates this enhancement into the JacksonStreamingSerializer infrastructure. Modifications: Before this changeset, the ByteArrayParser (and corresponding feeder) were the only choice when using the streaming deserialization infrastructure in Jackson, so the code was able to eaglerly initialize the parser and feeder. Now there is a choice that can be made at runtime which parser might be the best one based on the incoming buffer in the stream. As such, the code now checks the first Buffer and then decides if either the array-backed or the bytebuffer-backed parser should be initalized. This also has the advantage that if no items are emitted on an empty stream, no parser needs to be initialized at all. Note that the code still preserves the runtime "backed by type" checks since (while likely not common but possible) buffers with different backing types can arrive one after another and need to be handled. In this case it is possible that a sub-optimal parser is chosen, but the code optimizes for the likely scenario that all buffers on one stream are backed by the same type. Result: Added support for Jackson's new ByteBufferFeeder and choosing the best strategy at runtime depending on the first buffer type that arrives.
daschl
added a commit
to daschl/servicetalk
that referenced
this issue
Nov 17, 2022
Motivation: In 2.14.0, Jackson added support for feeding ByteBuffers directly into the streaming parser engine (where previously only byte arrays would be supported). This changeset incorporates this enhancement into the JacksonStreamingSerializer infrastructure. Modifications: Before this changeset, the ByteArrayParser (and corresponding feeder) were the only choice when using the streaming deserialization infrastructure in Jackson, so the code was able to eaglerly initialize the parser and feeder. Now there is a choice that can be made at runtime which parser might be the best one based on the incoming buffer in the stream. As such, the code now checks the first Buffer and then decides if either the array-backed or the bytebuffer-backed parser should be initalized. This also has the advantage that if no items are emitted on an empty stream, no parser needs to be initialized at all. Note that the code still preserves the runtime "backed by type" checks since (while likely not common but possible) buffers with different backing types can arrive one after another and need to be handled. In this case it is possible that a sub-optimal parser is chosen, but the code optimizes for the likely scenario that all buffers on one stream are backed by the same type. Result: Added support for Jackson's new ByteBufferFeeder and choosing the best strategy at runtime depending on the first buffer type that arrives.
daschl
added a commit
to daschl/servicetalk
that referenced
this issue
Nov 30, 2022
Motivation: In 2.14.0, Jackson added support for feeding ByteBuffers directly into the streaming parser engine (where previously only byte arrays would be supported). This changeset incorporates this enhancement into the JacksonStreamingSerializer infrastructure. Modifications: Before this changeset, the ByteArrayParser (and corresponding feeder) were the only choice when using the streaming deserialization infrastructure in Jackson, so the code was able to eaglerly initialize the parser and feeder. Now there is a choice that can be made at runtime which parser might be the best one based on the incoming buffer in the stream. As such, the code now checks the first Buffer and then decides if either the array-backed or the bytebuffer-backed parser should be initalized. This also has the advantage that if no items are emitted on an empty stream, no parser needs to be initialized at all. Note that the code still preserves the runtime "backed by type" checks since (while likely not common but possible) buffers with different backing types can arrive one after another and need to be handled. In this case it is possible that a sub-optimal parser is chosen, but the code optimizes for the likely scenario that all buffers on one stream are backed by the same type. Also a MethodHandle-based runtime check has been added which makes sure that even if a user overrides the Jackson version to an older one on the Classpath the code is still functional. Result: Added support for Jackson's new ByteBufferFeeder and choosing the best strategy at runtime depending on the first buffer type that arrives.
daschl
added a commit
to daschl/servicetalk
that referenced
this issue
Dec 1, 2022
Motivation: In 2.14.0, Jackson added support for feeding ByteBuffers directly into the streaming parser engine (where previously only byte arrays would be supported). This changeset incorporates this enhancement into the JacksonStreamingSerializer infrastructure. Modifications: Before this changeset, the ByteArrayParser (and corresponding feeder) were the only choice when using the streaming deserialization infrastructure in Jackson, so the code was able to eaglerly initialize the parser and feeder. Now there is a choice that can be made at runtime which parser might be the best one based on the incoming buffer in the stream. As such, the code now checks the first Buffer and then decides if either the array-backed or the bytebuffer-backed parser should be initalized. This also has the advantage that if no items are emitted on an empty stream, no parser needs to be initialized at all. Note that the code still preserves the runtime "backed by type" checks since (while likely not common but possible) buffers with different backing types can arrive one after another and need to be handled. In this case it is possible that a sub-optimal parser is chosen, but the code optimizes for the likely scenario that all buffers on one stream are backed by the same type. Also a MethodHandle-based runtime check has been added which makes sure that even if a user overrides the Jackson version to an older one on the Classpath the code is still functional. Result: Added support for Jackson's new ByteBufferFeeder and choosing the best strategy at runtime depending on the first buffer type that arrives.
daschl
added a commit
to daschl/servicetalk
that referenced
this issue
Dec 1, 2022
Motivation: In 2.14.0, Jackson added support for feeding ByteBuffers directly into the streaming parser engine (where previously only byte arrays would be supported). This changeset incorporates this enhancement into the JacksonStreamingSerializer infrastructure. Modifications: Before this changeset, the ByteArrayParser (and corresponding feeder) were the only choice when using the streaming deserialization infrastructure in Jackson, so the code was able to eaglerly initialize the parser and feeder. Now there is a choice that can be made at runtime which parser might be the best one based on the incoming buffer in the stream. As such, the code now checks the first Buffer and then decides if either the array-backed or the bytebuffer-backed parser should be initalized. This also has the advantage that if no items are emitted on an empty stream, no parser needs to be initialized at all. Note that the code still preserves the runtime "backed by type" checks since (while likely not common but possible) buffers with different backing types can arrive one after another and need to be handled. In this case it is possible that a sub-optimal parser is chosen, but the code optimizes for the likely scenario that all buffers on one stream are backed by the same type. Also a MethodHandle-based runtime check has been added which makes sure that even if a user overrides the Jackson version to an older one on the Classpath the code is still functional. Result: Added support for Jackson's new ByteBufferFeeder and choosing the best strategy at runtime depending on the first buffer type that arrives.
|
Closing this ticket, see the reasoning in the commit msg of f3636fb |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Jackson currently does not provide any implementations for
ByteBufferFeederFasterXML/jackson-core#478. When it does we need to revisit how to use the Jackson APIs to prefer aByteBufferFeeder. The factory methods do not support a way to specify which feeder type to create.The text was updated successfully, but these errors were encountered: