-
Notifications
You must be signed in to change notification settings - Fork 6
Jackson3 Changes
NOTE: contents, discussion be moved to -- https://github.com/FasterXML/jackson-future-ideas/discussions/72.
This page NOT actively updated as of December 2024
- Jackson 3.x will likely require and be based on Java 17 (2.18 requires Java 8)
- Embed some/all Java8 modules
- Embed "parameter names", "datatypes" (
Optional
) - Need to think of Java 8 date/time module (size)
- Embed "parameter names", "datatypes" (
- Renaming/repackaging: see JSTEP-1
- Should we combine
databind
with "base modules" (mr-bean, afterburner, jaxb-annotations) for easier tracking of API change effects?
Plan is to immediately remove all things deprecated (but not yet removed) by version 2.9, including things that are part of Public API (which have been retained throughout whole 2.x cycle, unlike internal/package APIs).
This includes:
- Old JSON Schema generation that builds
JsonNode
(already deprecated)- Not actively maintained since at least 2.4, deprecated by visitor-based approach since then
- May want to rewrite visitor-introspection interface as well; too JSON Schema centric
Following are things that are thought to be removed as of now:
- Dataformat auto-detection (most in streaming, some in databind)
- supported by some formats, but complicated to make work at higher level
- Ability to re-configure
ObjectMapper
with different codec factory (JsonFactory
)- If codec factory is fixed since construction, allows databind/core to be more optimized, esp. for binary formats where name is not decoded from input but inferred from schema (
protobuf
,avro
) -- could lead to non-trivial performance improvements
- If codec factory is fixed since construction, allows databind/core to be more optimized, esp. for binary formats where name is not decoded from input but inferred from schema (
Following are features that were considered for removal but did not get removed
- Serializability of components (from
ObjectMapper
on)- Original justification was to allow "thaw"/"unthaw" for Android, but it is questionable whether observed improvement was due to use of JDK serialization, or something else (perf problem in setup)
- In general, idea of serializing active components is not a good idea: and making it explicit these are not serializable can even help resolve problems on systems like distributed data streaming processors (Spark, Storm etc)
- Lots of bits of extra code, removal of which would clean up codebase a bit; but more importantly, less code to maintain, test
-
22-May-2018: decided earlier that we can keep JDK Serializability quite easily for
ObjectMapper
, by serializing as separate state object- Many other helper objects NEED NOT be serializable, including (de)serializers; as long as
Module
s are rewritten to not (try to) serialize instances of these helper types.
- Many other helper objects NEED NOT be serializable, including (de)serializers; as long as
See JSTEP-2 for details.
-
ContextualSerializer
/ContextualDeserializer
,ResolvableSerializer
/ResolvableDeserializer
- just embed as part of
JsonSerializer
/JsonDeserializer
, with no-op implementation
- just embed as part of
In general, we would want to reduce mentions of "json" in cases where API is not JSON-specific.
This is pretty much of all jackson-databind
, and most of jackson-core
too -- after all, other dataformats
use same abstractions and there should be separate JSON implementation.
However: some of existing entities with json
in their name -- say, JsonProcessingException
, JsonParser
and JsonGenerator
-- are so widely used that renaming would cause so much work that it is questionable whether change would be worth the trouble. So, question becomes: what are the places where we could improve naming with limited amount of compatibility breakage (small amount is fine: 3.0 is backwards-incompatible).
-
JsonFactory
->TokenStreamFactory
?- Unlike
JsonParser
andJsonGenerator
, factory itself is not exposed in all that many places - Additional change: current
JsonFactory
would be split in two parts: general-purpose abstractStreamFactory
, and JSON-specificJsonStreamFactory
-- we do want to get rid ofJsonFactory
to avoid/reduce collision (since the new version is NOT a base class of other factories any more)
- Unlike
- Rename exceptions, esp.
JsonProcessingException
->JacksonException
-- base type not that often used-
JsonParseException
->StreamReadException
? -
JsonGenerationException
->StreamWriteException
? -
JsonMappingException
->DatabindException
-
-
JsonNode
needs major rework: see JSTEP-3 for details - XML module should have its own "Tree Model", distinct from
JsonNode
(but ideallyTreeNode
?) that handles- Duplicate element names (sequences, often representing Arrays)
- Distinction between XML elements, attributes