Jackson3 Changes

Proposed Jackson 3.0 changes

JVM/JDK Compatibility

• Jackson 3.x will require and be based on Java 8
  • with possible exception of jackson-core and jackson-annotations (?)

Structural

Maven modules (jars)

• Embed some/all Java8 modules
  • Embed "parameter names", "datatypes" (Optional)
  • Need to think of Java 8 date/time module (size)

Git Repos

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

Things to Remove

2.9 Deprecated

Plan is to immediately remove all things deprecated (but not yet removed) by version 2.9. 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 features

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

Further following features are up for discussion

1. 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
   • May still want to offer some level of explicit support for passing configuration of ObjectMapper / ObjectReader / ObjectWriter? That is, allow some form of externalizing settings, if possible (but may not be... perhaps only for some of settings)

Features

MapperFeature:

• USE_STD_BEAN_NAMING: should always be used, no need for old slightly differing algorithm

Entities

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

Major API change areas:

• JsonNode needs major rework; can do binary-incompatible return value changes

Changes to defaults

(will require wiki sub-page)

• MapperFeature
  • SORT_PROPERTIES_ALPHABETICALLY: default to true (false really doesn't make much sense since it is unstable, and arbitrary based on JVM/JDK)
• DeserializationFeature
  • READ_ENUMS_USING_TO_STRING: default to true (instead of false that relies on name())
  • FAIL_ON_UNKNOWN_PROPERTIES: default to false? (TOP REQUEST by users)
• SerializationFeature
  • FAIL_ON_EMPTY_BEANS: default to false
• Other
  • Check defaults of date/time handling

Misc Impl Changes

• JsonStreamContext: implement "currentValue" access in base class (remove from sub-classes)