(or, as Monty Python gang used to say, “And Now for Something Completely Different” — a minor break from my usual CS/Java writing)

Background: dissing my ethnic food roots

Over time, a few colleagues and friends in US have asked me about Finnish cuisine: what is it like, what are the good dishes etc. I have tended to answer along the lines of the (in)famous Churchill’s quote on Royal Navy (“rum and sodomy”), suggesting that Finnish food tradition consists mostly of variations meat and potatoes with a strong undercurrent of underseasoning.

While there is some truth to that quip, I have grown to realize over time…

aka POJOs are optional

As most Java developers know, Jackson is a very powerful library for converting between Plain Old Java Objects (POJOs) and various data formats, most notably JSON. By defining Java object — and especially with optional annotations — you can construct elaborate data structures to match almost any use case.
There is quite a bit of documentation showing how to do that; for example:

But while useful and often convenient, you do not really HAVE TO define Java classes write or read JSON with Jackson: for “casual” usage there are…

aka ObjectMapper.builder().[configure].build()

First the disclaimer: as I write this (end of Jan 2021), Jackson 3.0 is still very much Work-in-Progress (see earlier Jackson 3.0 vision): even the first release candidate is months away. My hope is to release the final 3.0 some time during 2021. Until then you can see the progress on master branches of Jackson repos and build locally, kick the tires, but should not use it for any real work.

With that out of the way, let’s look at the first major new feature that has been implemented for 3.0 (also listed on Jackson 3.0 …

State of Jackson 3.0 as of early 2021

The Jackson project is by now almost 14 years old: the first public version was released in the summer of 2007. A lot has happened over the years: a two dozen “minor” releases (ones with new features) from 1.0 through to 2.12 and more than 100 patch releases (ones with only bug fixes) have been released over the years.

But in addition there has been one transition known as the “major version upgrade”, in which the new version is not backwards-compatible with the older version. This occurred with the release of Jackson 2.0.0 …

(to rename and remove properties)

Something that I briefly covered earlier (in Jackson 2.11 features) is the new jackson-jr extension called jackson-jr-annotation-support. But as I have not gotten much feedback since that release, maybe it is time to re-review this additional functionality.
(note: if you are not familiar with Jackson-jr library itself, you may want to read “Jackson-jr for ‘casual JSON’” first before continuing)

Introduction of general “extension” mechanism for jackson-jr — not unlike full Jackson’s “modules” — coincided with the addition of first such extension, “jackson-jr-annotation-support”, which offers optional support for some of basic Jackson annotations for basic detection (and exclusion) of properties; renaming…

(continuation of “Deeper Dive on Jackson 2.12” mini-series — see “Jackson 2.12 Features” for context)

Aside from “big 5” features discussed so far, another major area of work this time around was that of Jackson XML dataformat module: no fewer than 26 XML-specific issues were resolved for this release.
As usual, you can see the full list of changes on 2.12 Release Notes; here we’ll dig deeper into most notable fixes and improvements.

Nested Lists in POJOs should work reliably (esp. unwrapped)

Before 2.12 content models with Collection/List valued properties worked well enough for single-level cases, but various combinations of unwrapped (see @JacksonXmlElementWrapper) Lists, nested deeper tended to have…

Support ‘java.lang.Record’

(part 5 of “Deeper Dive on Jackson 2.12” mini-series — see “Jackson 2.12 Features” for context)

And now the last “Most Wanted” feature: something requested quite recently (less than year ago) — databind#2709: support brand new java.lang.Record type, introduced in Java 14. Its implementation is a good example of collaboration (see 2.12 Acknowledgments), and the feature has generated a lot of excitement even before getting released.

Basic idea is pretty simple: Record values should behave very much like a POJO with @JsonCreator works. So, these two cases:

public class AsPojo { private final int x, y; @JsonCreator public AsPojo(@JsonProperty("x") int…

CoercionConfig system

(part 4 of “Deeper Dive on Jackson 2.12” mini-series — see “Jackson 2.12 Features” for context)

After going over couple of rather old feature requests, this one — jackson-databind#2113 — is slightly more recent, addressing requests users have made over past couple of minor versions: Jackson being sometimes too lenient in accepting secondary representations of values.

Background: need for type coercions

With default Jackson settings, you might have value type like:

public class State {
public boolean enabled;

and expect to read it from JSON content like:

{ "enabled" : true 

but you could also have content like:

{ "enabled" : 42 }{…

Annotation-less @JsonCreator (even 1-argument)

(part 3 of “Deeper Dive on Jackson 2.12” mini-series — see “Jackson 2.12 Features” for context)

Another long-requested feature — jackson-databind#1498 — was finally included in 2.12 as well, by introducing a new configuration setting called CosntructorDetector along with couple of default implementations to use.


The likeliest usage of this feature is something like:

ObjectMapper mapper = JsonMapper.builder()

but what exactly this does will require bit longer explanation.

Background: what is the problem

To understand the feature itself, let’s start with the problem being solved.
Consider this explicitly annotated POJO:

public class Point {
private int x, y;
@JsonCreator(mode = JsonCreator.Mode.PROPERTIES) public…


(part 2 of “Deeper Dive on Jackson 2.12” mini-series — see “Jackson 2.12 Features” for context)

Another rather old Jackson Feature Request — jackson-databind#1296 from summer of 2016 — was also included in Jackson 2.12.0 release.
This feature request was asking for something similar to existing @JsonIgnoreProperties annotation which works like so:

@JsonIgnoreProperties({ "password" })
public class Stuff {
public int id;
public String name;
public String password;
// serialized as:
{ "id" : 124, "name" : "thingy" }

in this case serialization of value of property password would be prevented and only id and name properties would be…


Open Source developer, most known for Jackson data processor (nee “JSON library”), author of many, many other OSS libraries for Java, from ClassMate to Woodstox

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store