NOTE: contents, discussion be moved to https://github.com/FasterXML/jackson3-dev -- this page NOT actively updated as of 24-Sep-2017.

---

Proposed Jackson 3.0 changes

JVM/JDK Compatibility

• Jackson 3.x will like require and be based on Java 17 (2.16 requires Java 8)

Structural

Maven modules (jars), Java packages

• Embed some/all Java8 modules
  • Embed "parameter names", "datatypes" (Optional)
  • Need to think of Java 8 date/time module (size)
• Renaming/repackaging: see JSTEP-1

Git Repos

• Should we combine databind with "base modules" (mr-bean, afterburner, jaxb-annotations) for easier tracking of API change effects?

Things to Remove

Anything deprecated during 2.x

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:

1. 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

Major Functionality

Following are things that are thought to be removed as of now:

1. Dataformat auto-detection (most in streaming, some in databind)
   • supported by some formats, but complicated to make work at higher level
2. 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

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 Modules are rewritten to not (try to) serialize instances of these helper types.

XxxFeatures

See JSTEP-2 for details.

Entities

• ContextualSerializer / ContextualDeserializer, ResolvableSerializer / ResolvableDeserializer
  • just embed as part of JsonSerializer / JsonDeserializer, with no-op implementation

(Re)Naming

jackson-core renamings

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 and JsonGenerator, factory itself is not exposed in all that many places
  • Additional change: current JsonFactory would be split in two parts: general-purpose abstract StreamFactory, and JSON-specific JsonStreamFactory -- we do want to get rid of JsonFactory to avoid/reduce collision (since the new version is NOT a base class of other factories any more)
• Rename exceptions, esp. JsonProcessingException -> JacksonException -- base type not that often used
  • JsonParseException -> StreamReadException?
  • JsonGenerationException -> StreamWriteException?
  • JsonMappingException -> DatabindException

Major API change areas

• JsonNode needs major rework: see JSTEP-3 for details
• XML module should have its own "Tree Model", distinct from JsonNode (but ideally TreeNode?) that handles
  • Duplicate element names (sequences, often representing Arrays)
  • Distinction between XML elements, attributes