Jackson Release 2.13 - FasterXML/jackson Wiki

Jackson Version 2.13 was released on September 30, 2021. Two release candidates (2.13.0-rc1, 2.13.0-rc2) were released prior to the final 2.12.0.

This wiki page gives a list of links to all changes (with brief descriptions) that were included.



Changes, compatibility

Compatibility: JDK requirements

Plan (as of 2020-01-20) is to increase JDK baseline to Java 8 for jackson-databind and other components that so far (up until 2.12) have only required Java 7 (but not including ones that only require Java 6 -- jackson-annotations, jackson-core and jackson-jr -- which will retain Java 6 minimum).

Benefits include:

  1. Ability to embed one or both of "Java 8 datatypes" (Optional and related) and "Java 8 parameter names" (auto-discovery of constructor parameters) -- eventually, but not in 2.13
  2. Convergence with 3.0 plans: can add configuration methods that take closures (modifications of "Config Overrides" and "Coercion Configs" in particular)
  3. Ability to use Java 8 functional aspects in API in general for both 2.x and 3.0

Compatibility: Build changes

The new jackson-jakarta-rs-providers requires JDK 11 to build (due to Jetty test dependency); other modules still only need JDK 8.

Compatibility: Module changes

Compatibility: Dependency changes:

Changes, behavior


New Modules

TOML Dataformat Module

New module -- jackson-dataformat-toml -- now included in jackson-dataformats-text, supports TOML.

Jakarta variants to replace Javax modules

To allow working around the Oracle-created "Javax vs Jakarta" problem, Jackson 2.13 introduces hard forks of 3 kinds of existing modules (see below). You (or your platform/framework) will need to change dependencies appropriately, to get the module needed for your Jakarta-or-Javax APIs (hooray for interoperability).

Note that these modules will obsolete Jackson 2.12 use of "-jakarta" classifier for JAXB and JAX-RS provider modules.

Jakarta XML Bind (jakarta.xml.bind) annotations

New module -- jackson-module-jakarta-xmlbind-annotations -- added in "jackson-modules-base", as alternative to existing "old" JAXB Annotations module.

Jakarta-RS providers

New modules with names like jackson-jakarta-rs-json-provider (for cbor, smile, xml and yaml) as alternatives to existing "jackson-jaxrs-[FORMAT]-provider" providers.

Jakarta JSONP datatype

New module, jackson-datatype-jakarta-jsonp added as the replacement for Javax/JSON-P supporting jackson-datatype-jsr353.

Jakarta Mail datatype

New module, jackson-datatype-jakarta-mail added to support a small subset (one class, jakarta.mail.internet.InternetAddress) of Jakarta Mail (ex "Java Mail") library.

"No Constructor" Deserializer module

New module -- jackson-module-no-ctor-deser -- now included in jackson-modules-base -- added to support a very specific use case of POJOs that do not have either:

  1. No-arguments ("default") constructor, nor
  2. @JsonCreator annotated constructor or factory method

in which case module can force instantiation of values without using any constructor, using JDK-internal implementation (included to support JDK serialization itself). Note that this module may stop functioning in future, but appears to work at least until JDK 14.

Module deprecation, removal

Hibernate 3 module: drop

Due to low-to-no usage of Hibernate 3 module (as compared to Hibernate 4 and 5), Hibernate 3 module (jackson-datatype-hibernate3) will be dropped from 2.13, as per datatype-hibernate#139.

(NOTE: whether Hibernate module will be released for Jackson 3.x is an open question too, due to the lack of maintainers)

Major focus areas planned -- but postponed due to lack of time

(Finally) Rewrite Creator Detection wrt Property Discovery

A class of impossible-to-fix problems related to Creator methods (constructors, factory methods) is due to "duality" of Creator discovery and General property discovery. Problem is that the process goes like this:

  1. General property discovery is performance by POJOPropertiesCollector: this is based on finding regular accessors (Fields, Getter/Setter methods) using both name-based auto-discovery and annotations, but also includes (annotated) Creator property parameters -- but notably not parameters of possible implicit (auto-discovered) Constructors. Accessors are combined into logical properties, expressed as (and accessed through) BasicBeanDescription container.
  2. BeanDeserializerFactory takes BasicBeanDescription and introspect possible Creators: this starts from scratch and finds potential Creators both by explicit annotations and possible auto-discovery. It will also try to combine already known Properties (from step 1) with now-located Creator parameters.

... and the problem is that "implicit" Creators -- ones with no explicitly annotated parameters (note: Not related to annotation of Creators method itself, but to parameter annotations!) -- will not be known during step (1) and as such will:

Fixing this general problem by either:

  1. Moving Creator discovery as part of POJOPropertiesCollector (preferred), or
  2. Trying to combine pieces in step 2 more throughly (could resolve some of the issues)

would fix some of existing failing tests, and in particular help with newly found problems with Record handling (added in 2.12).

Configurability ideas similarly deferred

Separate configuration settings for:

JsonNode config/feature

Part of/related to JSTEP-3, it'd be good to have a set of simple on/off features to configure read/write/transform aspects of JsonNode, distinct from POJOs.

These settings should ideally be per-call, similar to [De]SerializationFeature.

Date/Time config/feature(s)

Part of/related to JSTEP-5 (and JSTEP-6), there are things that should be easily configurable as on/off "features", or similar configuration object(s).

One challenging part is that some of the settings should probably be per-call ones (i.e. can change on specific read/write); whereas others must be per-mapper (unchangeable after construction)

Enum read/write features

Handling of Enum value reading, writing, is currently configured with a hodge-podge of SerializationFeature / DeserialiationFeatures, but as with JsonNode and Date/Time values, that's not a good place as those should be for more general aspects of handling. This is covered to some degree in JSTEP-6.

So we should like have EnumFeatures too, changeable on per-call basis; partly to replace existing [De]SerializationFeatures (for 3.0), and partly to expose new ones.

Processing Limits (if time allows)

Mentioned as one future JSTEP on https://github.com/FasterXML/jackson-future-ideas/wiki/JSTEP, there really should be limits to maximum size and/or complexity of input to process, mostly to prevent potential DoS attacks (as well as accidental "intern brought down our system by broken script" cases). There is some prior art in Woodstox, for example (see Woodstox-specific settings ("limits")).

Changes implemented so far

Full Change list

Changes, core




Changes, data formats








Changes, datatypes


Java 8 date/time

Joda Money

Changes, Other modules



Changes, JAX-RS providers

Changes, JVM Languages


Changes, other