The “Big Fix” minor version

The most notable thing about this version is probably the sheer number of changes — mostly fixes, as usual — 143 in total (80 of them in jackson-databind).
The number of changes is among the highest for any release, likely second only to the preceding 3.0.0 (164 listed changes).

Many of the issues resolved were quite old: three had been filed more than 10 years ago — oldest, [databind#221], dating back to May 2013! — and 30 of them 5+ years ago.
So 3.1.0 can fairly be described as a bit of a “spring-cleaning” release.

The first 3.x Long-Term Support (LTS) version

One noteworthy thing is that 3.1 is the first LTS (see [JSTEP-13]) version in 3.x series. This means that it will be kept open longer than following non-LTS versions. With 3.1.0 release, 3.0 branch is now closed (no more patch releases planned).
With 3.1.0 release, Jackson now has 3 LTS branches: 2.18, 2.21 and 3.1.

Show Me The Changes!

For the full listing of all changes, see Jackson 3.1 Release Notes.
But let’s have a look at the highlights of 3.1.0 — aside from bug fixes there are plenty of improvements and even some new features.

SBOM publishing fixed

Although 3.0 build did produce CycloneDX SBOM artifacts (as per JSTEP-14), Maven publishing did not upload these as part of the version publishing, rendering this feature mostly useless (one could locally publish these but not access via Maven Central).

But 3.1.0 release published the artifacts: for jackson-databind we have (see https://repo1.maven.org/maven2/tools/jackson/core/jackson-databind/3.1.0/):

jackson-databind-3.1.0-sbom-cyclonedx.json        2026-02-23 21:13      8641
jackson-databind-3.1.0-sbom-cyclonedx.xml         2026-02-23 21:13      7755

Fix here was the same as in 2.21.0. It will be interesting to see if SBOM support proves useful or not — I have not received much (any) feedback since 2.21 release.

Most Wanted issues: 3 resolved

“Most Wanted” for Jackson means issues (mostly in jackson-databind) with at least 5 upvotes: of these 3 were resolved by 3.1.0:

• [databind#1196]: Add support for collecting multiple deserialization failures during processing, not just first one
• [databind#1516]: Problem with multi-argument Creator with `@JsonBackReference` property
• [databind#1981]: Add method remove(JsonPointer) in ContainerNode (ArrayNode/ObjectNode)

This leaves about a dozen most-wanted issues still open. Jackson 3.2.0 being developed will fix at least one more.

Most Wanted [databind#1196]: Add support for collecting multiple deserialization failures

The oldest most-wanted issue is probably the most interesting addition.
It builds on existing DeserializationProblemHandler feature: DeserializationProblemHandler allows registering a handler to try to resolve about 10 types of recoverable deserialization problems, from mismatching property names to missing type ids.
In 3.1.0 anew problem handler implementation, CollectingProblemHandler, was added. It will not only provide default handling for problems (mostly just ignoring the issue, providing filler value and so on), but will also collect info on reported problems themselves. The idea is that instead of the read process immediately failing with an exception on the first issue encountered, all problems (up to configurable maximum, by default first 100) are collected to be reported as a set of issues using specific new exception type, DeferredBindingException.

Feature is used like so:

ObjectReader reader = MAPPER
   .readerFor(Person.class)
   .problemCollectingReader();
Person p;

try {
    // note: separate read() call as well
    p = reader.readValueCollectingProblems("{ \"name\": \"Bob\" }");
    // if we get here, read succeeded normally
} catch (DeferredBindingException e) {
    List<CollectedProblem> probs = e.getProblems();
    int ix = 0;
    for (CollectedProblem prob : probs) {
       System.err.printf("Issue #%d at %s: %s.\n",
          ++ix, prob.getPath(), prob.getMessage());
    }
} catch (JacksonException e) {
    // Caught non-recoverable problem (invalid JSON etc)
}

Most Wanted [databind#1516]: Problem with multi-argument Creator with `@JsonBackReference` property

This issue was about a bug in handling of cases like this:

// [databind#1516]
class ParentWithCreator
{
    String id, name;

    @JsonManagedReference
    ChildObject1 child;

    @JsonCreator // optional annotation in 3.x
    public ParentWithCreator(String id, String name, ChildObject1 child) {
        this.id = id;
        this.name = name;
        this.child = child;
    }
}

class ChildObject1
{
    public String id, name;

    @JsonBackReference
    public ParentWithCreator parent;

    @JsonCreator // optional annotation in 3.x
    public ChildObject1(String id, String name, ParentWithCreator parent) {
        this.id = id;
        this.name = name;
        this.parent = parent;
    }
}

which formerly failed but now works in 3.1.0.

Most Wanted [databind#1981]: Add method remove(JsonPointer) in ContainerNode

And the last “most-wanted” issue was about a simple method addition.
Now following works:

// NOTE: JsonNode.asObject() added in 3.1 as well (see below)
ObjectNode doc = objectMapper.readTree(json).asObject();
JsonNode maybeRemoved = doc.remove(JsonPointer.compile("/name/first");
// maybeRemoved either node removed (if there was one), or `MissingNode` (if not)

New feature: support alternate radixes (base X) when reading/writing Numbers as (JSON) Strings

The second oldest issue resolved (filed almost 13 (!) years ago) — [jackson-databind#221] — allows reading and writing of “Stringified” numbers using different base (radix) than 10 — for example hexadecimal (base-16).
“Stringied numbers” mean Java numbers written as/read from JSON Strings, not Numbers; alternate radixes are supported for integral number types (byte, short, int,long , BigInteger).

Usage is either by annotations like so:

class HexAddress {
  // Read/write as Stringified Hex
  @JsonFormat(shape=JsonFormat.Shape.STRING, radix=16)
  public int long memAddress;
}

HexAddress hex= new HexNumbers();
hex.memAddress = 64;

JsonMapper mapper = new JsonMapper();
String json = mapper.writeValueAsString(hex);
assertEquals("{\"memAddress\":\"40\"}", json);
Hex result = mapper.readValue(json, HexAddress.class);
assertEquals(64, result.memAddress);

or by configuring certain number types to default to alternate handling using standard Jackson “Config Overrides” mechanism:

ObjectMapper mapper = jsonMapperBuilder()
  .withConfigOverride(long.class,
    o->o.setFormat(JsonFormat.Value.forShape(JsonFormat.Shape.STRING).withRadix(HEX_RADIX)))
      .build();

New feature: non-buffering large reads of String values

Another old issue (in fact THE oldest one resolved by 3.1.0) from 2012 (originally [jackson-core#15] — but re-filed as [jackson-core#1228]) — requested addition of streaming alternative for JsonParser.getText() :

public class JsonParser {
  // New in 3.1!
  public long readString(Writer writer) throws JacksonException;
}

which could be used to access very long JSON String values incrementally, without buffering the whole String in memory (or at least without allocating full String).

This has been implemented for streaming JSON parser backends, as well as DataInput backed one; it is not implemented for non-blocking (async) parser (since it cannot really be implemented wrt Writer being blocking).

Default implementation used by non-JSON format backends does still full buffering — feel free to create issue requesting implementation by specific format backend if interested (implementation has to be done on format-by-format basis unfortunately, but addition is easier with JSON implementation as guideline; esp. by GenAI coding agents).

New annotations: @JsonDeserializeAs, @JsonSerializeAs

One feature added in 2.21.0 that is also included in 3.1.0 is the addition of 2 new “general” annotations (added in jackson-annotations 2.21): they were added to replace use of databind-specific older equivalents (@JsonDeserialize(as=…), @JsonSerialize(as=…)):

interface Value { ... }
class ValueImpl implements Value { ... }

class MyBean2 {
  @JsonDeserializeAs(ValueImpl.class)
  public Value value;
}
class MyOtherBean2 {
  @JsonSerializeAs(Value.class)
  public ValueImpl value;
}

See “Jackson 2.21 Released” for the full explanation.

Improvements to JsonNode functionality

In addition to [databind#1981] mentioned earlier (“Most Wanted” feature #3), a few other improvements are also included: improvements that help with streaming/functional style of working with JsonNode values:

1. [databind#2343]: “Add JsonNode.asArray() and JsonNode.asObject() methods”. This adds simple streaming cast methods:
   ObjectNode doc = objectMapper.readTree(json).asObject();
   which either cast or throw JsonNodeException (if it not of asserted type)
2. [databind#3884]: “Add ObjectNode.put(JsonPointer, JsonNode) method”:
   doc.put(JsonPointer.compile(“/a/b/c”), doc.textNode(“value”));
3. [databind#5558]: “Change defaulting of JsonNode.asXxx(defaultValue) /JsonNode.asXxxOpt() for NullNode“
   As per title, this means that explicit null values in content will be considered same as “missing” values, and default/empty values will be returned instead of Java null (unlike in 3.0)
4. [databind#5579]: “Add JsonNode.map()method“
   String result = node.map(n -> n.asString().toUpperCase());
5. [databind#5581]: “Add functional conversion methods JsonNode.nullAs(), JsonNode.missingAs()“
   Adds 2 convenience methods for replacing NullNode s (from JSON nulls ) and MissingNodes (references to non-existing parts of JSON trees) in streams with specified or suppliedJsonNode :
   String result = node.nullAs(nullReplValue).missingAs(()->defaultValue()).asString();
6. [databind#5586]: “Change IndexOutOfBoundsException that ArrayNode.set()/replace() throw to JsonNodeException”.
   Just what it says: avoid JDK IOOBE, throw Jackson’s own exception(s) as necessary.

Improvements to JDK Record type handling

Handling of JDK Record types was improved as well; here are the noteworthy fixes:

• [databind#3079]: “Support ObjectMapper.updateValue() for Record classes”. [NOTE: also supports ObjectMapper.readerForUpdating()].
  This was an interesting improvement to implement and relies on strict structure of Record types. Now simple usage works as expected:

MyRecord orig = new MyRecord(123, "Bob");
MyRecord updated = objectMapper.updateValue(orig, Map.of("name", "Bill"));
assertEquals(new MyRecord(123, "Bill"), updated);

// or
MyRecord updated2 = objectMapper.readerForUpdating(orig)
   .readValue("{\"id\": 456}");
assertEquals(new MyRecord(456, "Bob"), updated2);

Note: Records being immutable, a new instance will (need to be) created and returned.

• [databind#4157]: “Add MapperFeature.INFER_RECORD_GETTERS_FROM_COMPONENTS_ONLY to ignore getter method auto-detection for Records”
  This feature, when enabled, will turn off auto-detection of “classic” (get-prefixed) getters and only auto-detect (a) Record components and (b) explicitly annotated getters (@JsonProperty), like so:

record PersonRecord(String name, int age) {
  // Helper method that is NOT a record component
  public String getDisplayName() {
    return name.toUpperCase();
  }
  @JsonProperty
  public int extra() { return 42; }
}
String json = objectMapper.writeValueAsString(
  nwe PersonRecord("Bob", 37));
// json ->
//
// {"name":"bob","age":37,"extra":42}

so we will not be getting “displayName” property.

• [databind#5223]: “Java Records missing type information with DefaultTyping.NON_FINAL (add DefaultTyping.NON_FINAL_AND_RECORDS)”
  Handling of Record types can be problematic with Default Typing as Record types are final — so now there is anew DefaultTyping — NON_FINAL_AND_RECORDS , similar to existing NON_FINAL_AND_ENUMS.

Other improved modules

And for the rest of modules we had a few important fixes as well.

Improved modules: data formats

Aside from core modules (jackson-core, 11; jackson-databind, 80 issues resolved), most improvements were to data format modules, with total of 33 issues resolved. Here are most notable ones:

Improved dataformat: Avro

• jackson-dataformat-avro: [avro#514] “Update to Apache Avro 1.12.1 — the latest version of Apache Avro is now used (when using Apache backend for writing (always) or reading (optional)”

Improved dataformat: CSV

• csv#479: “ STRICT_CHECK_FOR_QUOTING does not quote value that contains newline character”
• csv#579: “Incorrect detection of missed columns in header line if columns reordering is enabled”
• csv#601: “Reader should allow separating plain nullValue and quoted value "nullValue" “
• csv#608: “Fix issue with UTF-8 surrogate pair decoding”
• csv#613: “Support StreamReadConstraints.maxDocumentLength() validation for CSV module”

Improved dataformat: YAML

• yaml#568: “YAML — ScannerException on block scalar “\n””
• yaml#590: “Upgrade to the latest version of SnakeYAML Engine (3.0.1)”
• yaml#596: “Port YAMLAnchorReplayingFactory from 2.x and improve it to handle nested anchors”
• yaml#608: “Fix issue with UTF-8 surrogate pair decoding”
• yaml#609: “Catch and rethrow yaml engine internal exception on generation”

Improved modules: Guava datatype

• guava#211: “ GuavaMultimapDeserializer does not respect JsonFormat.Feature.ACCEPT_SINGLE_VALUE_AS_ARRAY“

Improved modules: Blackbird

• blackbird#334: ” BlackbirdModule does not implement java.io.Serializable“

Improved modules: Mr Bean

• mr-bean#320: “Remove byte-buddy shading from 3.1 MrBean” — now ByteBuddy is included as a regular dependency, solving possible issues with JPMS.

Next Up: Jackson 3.2 with Yet More Fixes!

So the next thing to focus on is 3.2 — and its focus will remain on clearing up the backlog: while 3.2 brough down jackson-databind open issue count from over 300 closed to 200, there’s still way to go.

So far 3.2 has about 30 fixes (see Jackson Release 3.2 page) but as with 3.1, the focus in on clearing the backlog focusing with oldest open issues — these tend to be hardest ones to solve. Still, progress now is faster than for preceding 10 years or so!

Stay tuned. :)

Another “small” minor version

Since “the Big 3.0” was released between 2.20 and 2.21, the pace of change for Jackson 2.x development has slowed a bit. But while still a smallish minor release, 2.21.0 contains over 50 changes — about same as 2.20 — mostly fixes, and spread more evenly across components (usually more than half are for jackson-databind, this time just 1/3).

Another Long-Term Support (LTS) version

One noteworthy aspect of 2.21 is that it is designated as the second LTS (see [JSTEP-13]) version in 2.x serious (2.18 is the first). This means that it will be kept open longer than following non-LTS versions: and with release of 2.21.0, open 2.x branches now are 2.18 , 2.21 and 2.x head (for 2.22 and further versions).

Show Me The Changes!

For full listing of all changes, see Jackson 2.21 Release Notes. But let’s have a look at the highlights of 2.21.0.

New Module: SPI Subtypes

A new module was contributed and added to Base Modules repo: jackson-module-spi-subtypes. Module supports external (META-INF/services/) declaration of polymorphic subtypes — that is, to remove need to use @JsonSubTypes annotation linking base type(s) to subtype(s).
For full example see module README.md.

Module is added as usual:

ObjectMapper mapper = JsonMapper.builder()
    .addModule(new SubtypesModule())
    .build(); 

and then works as expected.

SBOM publishing fixed

Although Maven build in 2.20 produced CycloneDX SBOM artifacts (as per JSTEP-14), Maven publishing did not upload these as part of version publishing, making this a theoretical feature (one could locally publish these but not access via Maven Central).

But 2.21.0 now has the artifacts: for jackson-databind we have (see https://repo1.maven.org/maven2/com/fasterxml/jackson/core/jackson-databind/2.21.0/):

jackson-databind-2.21.0-sbom-cyclonedx.json       2026-01-18 23:06      7127
...
jackson-databind-2.21.0-sbom-cyclonedx.xml        2026-01-18 23:06      6628

It will be interesting to see if SBOM support proves useful; there has been a lot of talk about Supply-Chain Attacks for dependencies, automation of sbom generation use, but seeming lack of actual implementations.

Most Wanted Feature: Injection-only @JacksonInject

“Most Wanted” issues for Jackson are ones with at least 5 upvotes.
One such issue — [jackson-databind#1381]— was fixed for 2.21.
Idea here is that originally value for properties marked with @JacksonInject could always come either from JSON _OR_ injected (with JSON having precedence). But now it is possible to specify that only injection is allowed (and value, if any, from JSON is ignored):

class MyBean {
  // inject-only property, never deserialized from input,
  // but injection required
  @JacksonInject(value = "id", useInput = OptBoolean.FALSE)
  protected String injectedId;

  // Optionally injected property: never from input, injected
  // if injected value specified
  @JacksonInject(value = "description", useInput = OptBoolean.FALSE,
     optional = OptBoolean.TRUE)
  protected String description;

  // regular, non-injected property, deserialized from input
  public String value;
}  

This feature also work relatively newly (in 2.20) added property @JacksonInject.optional which allows specifying that injection may or may not be done, based on if value to inject is specified for ObjectMapper or ObjectReader:

// No Injectable values for mapper
ObjectMapper mapper = JsonMapper.builder().builder()
// but add to ObjectReader
ObjectReader r = mapper.readerFor(MyBean.class)
  with.injectableValues(new InjectableValues.Std()
    .addValue("id", "123"));
// Will inject in property `injectedId` but not to `description`
MyBean bean = r.readValue(json);

@JsonDeserializeAs, @JsonSerializeAs

To indicate more specific subtype for deserialization, it was already possible to use JsonDeserialize(as = <subclass>}:

interface Value { ... }
class ValueImpl implements Value { ... }

class MyBean {
  @JsonDeserialize(as = ValueImpl.class)
  public Value value;
}

and similarly to specify that a value is serialized as a _supertype_ (less commonly used — used to drop properties of concrete subtypes):

class MyOtherBean {
  @JsonSerialize(as = Value.class)
  public ValueImpl value;
}

(note: there are also separate properties to specify “content” type — for array and Collection elements, Map values) — and “key” type — for Map keys)

These worked but had one problem wrt Jackson 2.x/3.x compatibility: @JsonDeserialize and @JsonSerialize are NOT defined in standard jackson-annotations package but in jackson-databind itself — making them version-dependant. But use of new annotations included in 2.21 jackson-annotations avoids need to use version-specific annotations:

interface Value { ... }
class ValueImpl implements Value { ... }

class MyBean2 {
  @JsonDeserializeAs(ValueImpl.class)
  public Value value;
}
class MyOtherBean2 {
  @JsonSerializeAs(Value.class)
  public ValueImpl value;
}

Other updated modules

Besides changes to all 3 core modules, there were changes to 14 others — and almost every format backend. This includes:

CSV: 2 fixes

• [dataformats-text#10]: Missing `null` writes when writing `Object[]` values
• [dataformats-text#479]: `STRICT_CHECK_FOR_QUOTING` does not quote value that contains newline character

XML: support duplicate detection

• [dataformat-xml#114]: implement duplicate detection from XML backend: detection works for most other backends (JSON, CBOR, Smile, YAML at least)

Jackson-jr: 3 improvements

• [jackson-jr#176]: Cannot Deserialize JSON with `@JsonProperty`-annotated Record fields
• [jackson-jr#208]: Support reading of `double[]`
• [jackson-jr#210]: Support reading `boolean[]`/`short[]`/`float[]` values

Side note: Claude Code is here!

NOTE: [jackson-jr#210] mentioned above was the very first issue I used Claude Code to implement — and based on positive experience, have started to use more widely. In fact, of ~55 issues resolved in 2.21, more than a dozen — and likely about half (I don’t have exact count) — issues were solved with Claude assistance: some completely, some partially, but all fully reviewed of course.

Next up: Jackson 3.1 (another LTS version)

So, with 2.21.0 out — and importantly, jackson-annotations that went with it — focus will shift back to 3.x development.
Jackson 3.1.0-rc1 was released a week ago (Jan 28, 2026) and we hope to get some feedback before GA — but that release should go out within 2 weeks.
3.1 will likely be another LTS version (3.0 is not LTS), now that some minor compatibility issues have been resolved with 2.x->3.0 transition.

3.1 will be a Big Release — there are over 100 accumulated changes! (of which 4 are “Most Wanted” issue)— stay tuned!

When I wrote “Jackson 3.0.0 (GA) released” 2 weeks ago, I left one very important question unaddressed: Why Upgrade to Jackson 3?
Let’s consider this important question now that Jackson 3.0.1 patch is out.

1. New Jackson users: start with 3.0 if you can

First things first: if you have NOT used Jackson 2.x for your project — it’s green field development, or somehow never needed JSON (or another Jackson-supported format) handling—the choice of Jackson version is easier: unless you need to use platform/framework that only has Jackson 2.x support, you should consider starting with Jackson 3.0 because it:

1. Has cleaner API: no deprecated functionality
2. Is more ergonomic: better default configuration, embedded functionality; better (more consistent, intuitive) naming
3. Works better, out of the box, with modern JDKs (requires 17 but supports newer versions)
4. Is the actively developed major version getting all new features: 2.x will get some but not all as focus shifts to stability, risk minimization
5. While performance is currently comparable, 3.x is more likely to get optimizations (since these are “new features”, basically; and 2.x focuses on stability)

Having said that: aside from framework support there are two more things to consider:

• Due to significant internal changes, 3.0.0 probably has some (unreported) bugs that latest 2.x (2.20.0) does not have — but these will be reported and fixed quickly now that 3.0.0 (and, 3.0.1 with some fixes already) are public. If this is concerning, you may want to wait for a bit before jumping
• Most existing documentation on StackOverflow and elsewhere refers to Jackson 2.x API. While much of it is relevant/accurate regarding 3.0, not all is (wrt. Deprecated functionality), or is bit more work to use due to 3.x API changes (from simple renaming to signature changes)

Still: considering that you can avoid whole upgrade/conversion by starting with 3.x, it is probably the route to take if you can.

2. Existing users: converting Jackson 2.x based code; trade-offs

But if you have code that uses or is based on Jackson 2.x API, your trade-off is a bit different. While all the benefits I listed for “green field” (new app) usage above apply, there is the actual upgrade/conversion of code to consider (see Jackson 3 Migration Guide for an idea) — which may be a simple process or may be a big undertaking, depending on usage.
More work, possible disruption — more cost to justify.

3. Jackson 3.0.0: Big on Changes, not on New Features

First thing to acknowledge is the fact that while 3.0.0 IS “Big on Changes”, it is NOT Big on New Features. This is somewhat intentional: the focus was on making big internal changes to clean the code base; add support for new features, functionality; but not try implementing new “killer features” at the same time. Features themselves can and will be added incrementally: but the chance to make backwards-incompatible changes is one-off.
So we started with that. Obviously there is some risk in separating the two — it is not always clear which fundamental changes are needed for which features. But with 2.x branch having collected cruft and a backlog of desired changes, there was plenty to fix, extend, improve.
Those changes are now in.

So: Jackson 3.0.0 does not bring many new external features (more on this later on); they are likely not the reason to upgrade. Most new features, improvements are internal.

4. New features land on 3.x first, 2.x later (if at all)

With 3.0.0 release, focus of Jackson 2.x development changes: it will not be abandoned or moved to “maintenance mode” — not immediately, anyway — but there will be more emphasis on stability, risk reduction, safe fixes, fewer internal API changes (public API already covered by SemVer).
So “bigger” features (and fixes considered higher risk) will be made in 3.x branch first, and back-porting in 2.x will be considered separately.
Over time it is likely that most new features will be 3.x-only; and only critical security/data correctness fixes get back-ported in 2.x.

So the question of upgrading may be more about “when” than “if” — and for some legacy apps answer could be “never” — but for most actively developed/maintained timing is the main consideration.

5. 3.0.0: SOME new features

Having said that 3.0.0 is light on new features and functionality improvements, it is not completely devoid of them.

Let’s have a look at some (as usual full 3.0 Release Notes has all the details — this is but a sampling).

5.1 New Feature: Unchecked Exceptions

One change that can be very useful when working with Java Streams: change of Jackson API exceptions from checked (IOException-based) to unchecked (RuntimeException-based).
This change can remove lots of boiler-plate code for wrapping calls to ObjectMapper.readValue() (and similar).
Of course, existing code bases may encapsulate such wrapping in which case it’s not a big deal. YMMV.

5.2 New Feature: optional @JsonSubTypes for sealed classes

Another new feature is automatic subtype detection for sub-types of@JsonTypeInfo annotated sealed classes.
As per [databind#5025], you can have:

@JsonTypeInfo(use = JsonTypeInfo.Id.NAME, include = JsonTypeInfo.As.PROPERTY, property = "type")
// NO NEED TO ADD:
// @JsonSubTypes({
//    @JsonSubTypes.Type(value=ExampleChildA.class),
//    @JsonSubTypes.Type(value=ExampleChildB.class)})
public sealed class ExampleParent permits ExampleChildA, ExampleChildB {
}

@JsonTypeName(“a”)
public final class ExampleChildA extends ExampleParent {
}

@JsonTypeName(“b”)
public final class ExampleChildB extends ExampleParent {
}

that is, avoid use of @JsonSubTypes annotation.

5.3 Change: no more String.intern() by default

Another important change that could not be done for Jackson 2.x is [core#378]: disable use of String.intern() for parsed JSON Object property names (it can be enabled).

This was a long-requested feature, important for specific types of use cases with (hundreds of) thousands of distinct property names (such as “UUIDs as keys” usage).

5.4 Change: MethodHandle usage over Reflection

On performance front: one potentially useful change — see [databind#2083] — is that using JDK’s “new” (… since JDK 7) MethodHandle for dynamic access (calling setter, getter methods, constructors; field get/set access) over traditional Reflection API.
Although our performance testing failed to show meaningful performance improvement (that we were hoping for) it is possible that newer JDKs/JVMs would provide performance improvements; and the new access should work better overall (better error reporting).

5.5 Change: JsonNode API improvements

Without going into details (see [JSTEP-13] for details), API of JsonNode (Jackson’s “Tree Model”) was significantly improved in 3.0.0.
Some improvements are due to JacksonException change (5.1 above) allowing problems to be reported using exceptions (instead of returning null or default values); others by improved naming (renamed methods).

But the biggest functional change are extended and improved number accessors (see [databind#4958] f.ex).

It is worth noting that 2.x version was incrementally improved over time (since 3.0 branch was started at around Jackson 2.10 release) — so many of JSTEP-13 improvements are part of Jackson 2.20.

5.6 New Feature: “Shared” JsonMapper

[databind#2176] adds one seemingly small but useful thing:

JsonNode root = JsonMapper.shared().readTree(source);

That is: if you are fine with defaults, you can simply use a global default mapper instance. In addition to JsonMapper, shared instances of all format-specific mappers (YAMLMapper, CsvMapper, SmileMapper, …) exists too.

This addition required fully immutable ObjectMapper s, hence 3.x-only — in 2.x the problem would have been thread-safety (ability to try to (re-)configure shared mapper).

6. 3.0.0-only fixes, dependency upgrades

Besides 3.x-only features, some bugs present in 2.x cannot be fixed there.
Fix for issue [databind#4310] serves as an example.

Without going into details: the problem is that use of JDK @ConstructorProperties collides with implicit Constructor parameter names. This turned out to be next to impossible to fix in 2.20 (or later), but due to refactoring of 3.x code based and embedding of Parameter Names introspection in jackson-databind, trivial for 3.0.0.

Another kind of 3.x-only change is the one in YAML module (jackson-dataformat-yaml) — [dataformat-yaml#106] — to use new YAML parser package, snakeyaml-engine, over old SnakeYAML (both by same author), for YAML reading/writing.
This is important upgrade as snakeyaml-engine is actively maintained, has more features and so on — in a way mirroring Jackson 2.x->3.x upgrade itself.
Upgrade would be major hassle wrt backwards-compatibility in Jackson 2.x: but 3.0 can start with the new dependency.

7. So… Should I upgrade?

At the end of the day, there is no one general answer: “It Depends”.
But it is worth starting to think about the possibility.

I hope this blog post — along with earlier “Jackson 3.0.0 (GA) released” — helps by outlining what the benefits/trade-offs are, and how the Jackson 2.x vs 3.x development goals affect future releases, introduction of new features and improvements.

Jackson 3.0.0: when, why, what?

Jackson 3.0.0 was released last week, on October 3rd 2025. It is a big milestone for both the Jackson project and its user community. The “Jackson 3.0 Vision” post I wrote four years ago (!) still offers a good overview of the goals and key ideas behind this second major version bump (the first being 1.x->2.0 back in 2012). In essence, version 3.0 provides a clean foundation for long-term development: it removes accumulated technical debt, streamlines the architecture, and improves ergonomics in ways that were not possible within the constraints of minor releases. Rather than introducing many new features, this release focuses on addressing long-term challenges and enabling sustainable future evolution.

If you’d like to try out Jackson 3.0.0 — and you should! 🙂 — I recommend starting with the post “Taking Jackson 3.0.0-rc1 for a spin”. The instructions there still apply for the 3.0.0 GA release. And if you’re upgrading an existing Jackson 2.x codebase, be sure to check out the Migrating to Jackson 3 document— it covers the key changes and steps needed for a smooth transition.

“Introducing Jackson 3 support in Spring” explains the upcoming integration of Jackson 3.0 within the broader Spring ecosystem (huge thanks to the Spring Dev Team, especially Sébastien!) and provides valuable guidance for Spring Boot and Spring Framework users.

And finally, Jackson 3.0 Release Notes includes all documented changes between 2.20 and 3.0 versions.

With that out of the way, let’s take a look at what’s new in Jackson 3.0.

Overview of Jackson 3.0 high-level changes

1. Java Baseline is now 17

Whereas Jackson 2.x only requires Java 8, Jackson 3.0 requires Java 17.
This change simplifies Jackson support of post-Java8 features like Records. 3.0 also provides native support for Java Module system (JPMS), improving interoperability (2.x provides more limited support using Moditect plug-in).

Note that this is just the baseline: Jackson works with newer JDKs, all the way to (at the time of writing this) JDK 25, and can support post-JDK17 language/JDK features as well.

2. Maven group-id, Java package changed to tools.jackson

To allow Jackson 3.x co-exist with 2.x (co-exist meaning that 2.x and 3.x implementations do not collide in classpath), a new Maven group id and Java package names were chosen: tools.jackson (instead of com.fasterxml.jackson of 2.x) — see [JSTEP-1] for full discussion on reasons for doing this.

Necessary changes to work with these changes are detailed in Jackson 3 Migration Guide but the main ones are:

• Change Maven group id in the build files (pom.xml, build.gradle) by replacing com.fasterxml.jackson with tools.jackson for dependencies.
  For example, com.fasterxml.jackson.core becomes tools.jackson.core (for jackson-databind dependency).
• Change Java import statements similarly:

// from Jackson 2.x
import com.fasterxml.jackson.databind.ObjectMapper;
// to Jackson 3.x
import tools.jackson.databind.ObjectMapper;

2.1. Maven/Java package renaming exception: jackson-annotations

One exception to this general change is that com.fasterxml.jackson.annotation / jackson-annotations dependency remains unchanged: Jackson 3.0.0 components like jackson-databind depend on jackson-annotations version 2.20. As such neither jackson-annotations Maven dependency nor general Jackson annotation import statements change.

Unfortunately there is one further complication: in-package annotations — like com.fasterxml.databind.annotation.JsonSerialize which is part of jackson-databind and NOT jackson-annotations — do move and their imports need to be changed.

Reason for this exception is to allow the same core/general Jackson annotations to work with both Jackson 2.x and 3.x without any changes — this is explained in [JSTEP-1].

3. Removal of all Deprecated 2.x functionality (plus renaming)

One major benefit of a new major version is the ability to actually remove obsolete methods, fields and classes marked as @Deprecated in minor releases. With 3.0.0, everything marked as @Deprecated as of Jackson 2.20 has been removed — these were mostly methods with misleading names or obsolete signatures; but also include some obsolete Feature enum values.

In addition to Deprecated-things-removal, many existing core entities (classes) and methods, fields, were renamed — this was done as [JSTEP-6] and [JSTEP-8] efforts. For example:

• SerializerProvider (Jackson 2.x) was renamed as SerializationContext in 3.0 (to align with existingDeserializationContext)
• JsonParser.Feature s were renamed as either JsonReadFeature (JSON-specific) or StreamReadFeature (format-agnostic)

To help users’ upgrade process, Jackson 2.20.0 Javadocs have been augmented in places with descriptions of 3.0 replacements planned. These changes are incomplete: incremental work to update Javadocs continues, please let us know when you find missing cases.

Jackson 3 Migration Guide has sections on “Deprecated method/field/class/functionality removal” and “Core entity, method, field renaming” (although same caveat applies; sections are incomplete)

4. Changes to Default Configuration Settings, behavior

Beyond “cruft removal”, another important area of improvements is configuration settings: specifically the choice of default configuration settings. Many of Jackson 2.x defaults have proven sub-optimal, either based on user feedback (initial choice proven unpopular) or because the default was chosen for backwards-compatibility reasons.
Major version change allowed such default changes, under [JSTEP-2] (which lists all changes).

Examples include:

• DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES (enabled in 2.x; disabled in 3.0 by default) — changed due to strong user feedback (one of most highly-voted issue ever).
• MapperFeature.USE_STD_BEAN_NAMING (disabled in 2.x; behavior changed to enabled in 3.0) — originally added as an opt-in feature but really makes sense to always enabled.

5. Immutable ObjectMappers, Configure using Builder

Beyond configuration defaults, another long-term issue with Jackson 2.x configurability is the basic thread-safety (or lack thereof) of configuringObjectMapper instances. Although thread-safe configuration is not complicated — one just has to strictly follow “fully-configure-mapper-before-first-use” pattern — it is possible (and too easy) to use alternate, unsafe approach (configure, use, re-configure, try to use). Unfortunately not only is this possible but it may even work (or seem to work; or sometimes work). Or not. And if not, it is not obvious why.

Jackson 3.x solves this problem by making ObjectMappers fully immutable: the only way to configure mapper instances is by using builder-based construction:

JsonMapper mapper = JsonMapper.builder() // format-specific builders
   .addModule(new JodaModule()) // to use Joda date/time types
   .enable(JsonWriteFeature.ESCAPE_NON_ASCII) // configure streaming JSON-escaping
   .build();

One useful addition is the ability to create re-configured instances with rebuild():

JsonMapper mapper2 = mapper.rebuild()
   .enable(SerializationFeature.INDENT_OUTPUT)
   .build();

Builder-style configuration is also used for constructing now-immutable TokenStreamFactory instances (like JsonFactory, YAMLFactory):

YAMLFactory yf = YAMLFactory.builder()
    .enable(StreamWriteFeature.STRICT_DUPLICATE_DETECTION)
    .build();
YAMLMapper mapper = YAMLMapper.builder(yf)
    // configure as necessary
    .build();

As seen from examples, use of format-specific mappers (JsonMapper, YAMLMapper) is now required for construction: it is no longer possible to use generic ObjectMapper with format-specific TokenStreamFactory instances — no more new ObjectMapper(new YAMLFactory()) calls.

6. Unchecked exceptions (base JacksonException)

Original design for Jackson Exception hierarchy — starting with the base JsonProcessingException — built on the underlying blocking IO (java.io) read/write calls already exposing checked IOException — so Jackson API might as well “piggy-back” on that and make IOException the base of all Jackson exceptions.

This worked quite well until Java 8 and Streams (or functional programming in general) — but with that, use of checked exceptions has become a major inconvenience. So while there is still on-going debate within Java community on “checked vs unchecked exceptions”, it was decided that Jackson 3.0 switches to unchecked RuntimeException as the base. The new ultimate base exception is JacksonException — we took the opportunity to rename exception types too, to reduce use of “JSON” in places where there isn’t actual JSON-dependency.

For full scope of changes — and thinking behind changes — see [JSTEP-4].

7. Embedding of “Java 8 Modules”

Jackson 2.x has 3 add-on modules to support 3 features added by JDK 8:

• jackson-module-parameter-names: auto-detection of constructor parameter names (mostly to use with @JsonCreator )
• jackson-datatype-jdk8: support for java.util.Optional and other optional types (OptionalDouble, ...)
• jackson-datatype-jsr310: support for java.time Date/Time types

The reason the functionality was added as modules was because at the time Jackson (2.0 and early 2.x before 2.10 or so) only required Java 5; and to avoid requiring latest JDK 8 (at the time) it made sense to offer support via dynamically added modules.

But with Jackson long since having required Java 8 (and with 3.0 Java 17), it made sense to integrate this functionality: Jackson 3.0 has it all in default ObjectMapper. This means there are 3 fewer modules to register for typical usage.

A related change is the introduction of new DateTimeFeature configuration: it works for all Date/Time types supported (old java.util.Date/Calendar, Joda date/time; Java 8 java.time types):

JsonMapper mapper = JsonMapper.builder()
    // 3.0 defaults to writing Dates as ISO-8601; change to timestamps
    .enable(DateTimeFeature.WRITE_DATES_AS_TIMESTAMPS)
    .build();

8. Improved Tree Model (JsonNode)

And next-to-last but not least: Tree Model (JsonNode) has been significantly improved. For full changes please refer to [JSTEP-3], but highlights include:

• More configurability with JsonNodeFeature
• Ability to indicate failures with JsonNodeException (partly due to (6) above, “Unchecked exceptions”) — especially coercion failures
• More consistent naming
• More extensive coercion/conversion methods — intValue(), intValueOpt() , asInt() — across numeric types

9. Deprecated Modules: Hibernate data type, JSON Schema

One more thing… some modules have become semi-abandoned during 2.x development cycle:

• https://github.com/FasterXML/jackson-module-jsonSchema — obsolete by functionality, no owner, no development
• https://github.com/FasterXML/jackson-datatype-hibernate — functionality usable, occasional contributions but no owner/maintainer

and because of this, decision via [JSTEP-9] was to consider them deprecated. No upgrade effort to create (and thereby publish) 3.0.0 versions for either.

This is not a final decision: if maintainer(s) is/are found, Hibernate module(s) in particular may be “revived”. But unless that happens, only 2.x versions are available.

UPDATE, 2026–02–07: New maintainers have been found and so both modules ARE supported for 3.0

• Hibernate modules 3.0.0+ have been published
• JSON Schema module will exist starting with 3.1.0 (3.1.0-rc1 published)

X. Next Up: WHY use Jackson 3.0 over 2.0

Now that we know what 3.0 offers, we can (and should!) consider reasons for using Jackson 3 over established, trusted Jackson 2.

… in the next Blog Post. :)

When I last blogged about 3.0.0 release candidates, 3.0.0-rc4 was the latest one. That was almost 4 months ago.
Now that 3.0.0-rc9 is just out (get it while it’s hot!) — right after 2.20.0 was released, it’s been a crazy week — let’s see how progress towards 3.0.0 (THE Release) is going.

When 3.0.0-rc4 was The Thing

Back in April 2025:

• SBOM publishing support had been added
• Sonatype Central migration was just around corner (due to OSSRH publishing about to shut down)
• Thinking was we’d need 2 or maybe 3 more RCs to reach 3.0.0 final — we seemed to have most JSTEPs completed, defaults changed, entities renamed — just needed some feedback… (sidenote: [databind#1967] is a placeholder for “3.x migration guide”)

So how did things go?

Progress since 3.0.0-rc4: Sonatype Central publishing

First things first: Central Repository migration turned out less painful (imagine that) than I expected: 3.0.0-rc5 was published using Central, and earlier 2.x branches from 2.18 upwards were retrofitted as well (2.18 becoming the first Long-Term Support (LTS) Jackson version being the reason to backport that far). So that was a pleasant surprise.
Alas, migration did break one thing: SBOM publishing that was just added in rc4 :-(
(we still need to figure out how to fix that)

Progress since 3.0.0-rc4: ETA for 3.0.0

As to RCs needed to reach 3.0.0: we are now 5 RCs further — a bit more incremental work needed than expected but that’s all good. We may or may not need “just one more RC” but there is hope that 3.0.0-final MAY be released in September 2025!
This is the current goal.

One of the best things since 3.0.0-rc4 has been significant increase in feedback — from bug reports that started finally arriving, to direct contacts from Spring team regarding specific concerns (and always with solid reasoning). This has lead to some important additions, changes/modifications to default settings, for example. And lead to releasing RCs more often (“release early, release often”) to shorten the feedback loop, get everyone testing on the latest; giving more chances to effect how 3.0.0 works.

3.0.0-rc6/rc7: drop jackson-annotations 3.0

One important and far-reaching change is the versioning scheme change for jackson-annotations: after extensive Discussion, we agreed on changes to the original plan:

• Instead of releasing separate 3.x versions (3.0, 3.1, 3.2, …) of com.fasterxml.jackson.core:jackson-annotations (separate from all other 3.x components that have group id tools.jackson), it was decided that 3.x should simply keep on using 2.x annotations.
• Since there is no longer 1-to-1 mapping between jackson-annotations and other components (as 2.x and 3.x releases will not be synchronized either at patch or even minor level — while 2.20.x and 3.0.x will likely get released relatively closely spaced, further minor versions have their own cadence), it was also decided to drop patch level for Jackson 2.20 so jackson-annotations version released is 2.20 and no patches will be released.
• 3.0.0-rc7 was released with a dependency to jackson-annotations 2.20-rc1 (and 3.0.0-rc9 with 2.20 )

There is some confusion and possible pain resulting from this change for parts of Jackson 2.x user base — due to long reliance on a single version for all components — but this is one more reason to seriously consider using Jackson BOM for dependency management:

<dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>com.fasterxml.jackson</groupId>
      <artifactId>jackson-bom</artifactId>
      <version>2.20.0</version>
      <scope>import</scope>
      <type>pom</type>
    </dependency>   
  </dependencies>
</dependencyManagement>

which will hide this particular complexity as well as help overall.

At any rate: the hope is that this is the least painful way for smooth migration from 2.x to 3.x regarding annotations — which could otherwise be a serious speed bump (Jackson 1.x->2.x migration was negatively affected by separate jackson-annotations packages).

3.0.0-rc8: revert JsonWriteFeature.ESCAPE_FORWARD_SLASHES default change

Another significant change had to do with planned change to default escaping of “/” character.

Earlier, I was under impression that there was consensus on making “/” (forward slash) character escaped by default; based on handling by some other JSON packages (namely GSON). But after Polling developers I realized this changed was NOT regarded as somehing we should do.

So we changed that in 3.0.0-rc8. And there was much rejoicing. :)

3.0.0-rc9: remove URL-taking factory methods

One of last significant functionality Deprecations (2.x) and Removals (in 3.0) is for URL-taking factory/read methods:

• JsonFactory.createParser(URL source)
• ObjectMapper.readValue(URL source, Class<?> type)

The reason for this is difficulty of handling the life-cycle of the underlying HTTP connection, when relying on JDK-provided HTTP access (for details see [jackson-core#803])
Since this functionality is not really core competency of Jackson (caller can and should handle HTTP connections), it was deemed best to get rid of it for 3.x — and deprecate in 2.x (but not remove — it will remain for backwards-compatibility), as per [jackson-core#1462].

3.0.0-rc10?

So are we close to 3.0.0 release? I hope so — but as usual, you can help: take 3.0.0-rc9 out for a spin, let us know how it works. There is still time to address rough edges… but not for long. :)

2.20 by Stats

Starting by numbers, 2.20.0:

• Took 4 months from the previous minor release (2.19.0) — fastest minor release in years (2.19 itself was already quick, taking 6 months)
• Contains about 50 changes (mostly fixes, but some new features as well) — bit less than 80 in 2.19.

So we got another “small minor version”.

Background: preparing for 3.0.0, migration to Sonatype Central

One reason for short(er) development cycle (and fewer changes) is the focus on getting ready for 3.0.0 release. We are up to 3.0.0-rc8 by now, rc9 probably being released in a day or two, hopefully followed by 3.0.0 — goal being to release 3.0.0 in September 2025.
The reason this matters is that there are a few clean up things we want to synchronize between 2.x and 3.0 (complete 2.x deprecations (anything removed from 3.0 must have been deprecated by 2.20); change versioning schema of jackson-annotations (more on this below)). Basically changes that cannot go in a patch release of 2.19.
So to get 3.0.0 out in September 2025, it was important to get 2.20.0 released in August.

Another thing that pushed the new minor version was Sonatype’s EOL’ing of trusty old OSSRH repository, used for publishing to Maven Central.
While publishing changes were backported to 2.18 and 2.19 branches it was good to start the upgrade first in 2.20 branch (and verified with the release candidate).

But let’s check the actual changes: here are the highlights.

Most Wanted: support “iPhone” properties

As explained in [databind#5152], there is a problematic naming pattern for some JSON properties — something reported as an issue countless times over the years: so-called “iPhone” (or “oAuth”) properties.
Basically if a JSON property name:

1. Starts with upper-case letter(s) — like Phone OR
2. Starts with a single lower-case letter, followed by an upper-case letter — like iPhone (hence issue name)

there is ambiguity between external name (and possible Java Field name) and matching Bean Getter/Setter names: getter/setter inferred name does not match actual JSON property name.
Specifically following POJO fails to work without additional annotations:

class IPhone {
  private String iPhone;

  public String getIPhone() {
    return iPhone;
  }
}

because:

• Field iPhone — used for deserialization — expects JSON property “iPhone”
• Getter getIPhone() will produce JSON property “iphone” (or with MapperFeature.USE_STD_BEAN_NAMING “IPhone”) — because translation from getter (or setter) name is fundamentally ambiguous.

So, essentially, Jackson would write JSON like (since getter infers “iphone”):

{ "iphone": "xxx" }

but would expect to receive:

{ "IPhone": "xxx" }

This is particularly problematic with frameworks like Lombok.
Solution before 2.20 has been to use annotations to unify names:

class IPhone {
  private String iPhone;

  @JsonProperty("iPhone")
  public String getIPhone() {
    return iPhone;
  }
}

But now there is finally a way to handle these cases gracefully without annotations — by enabling new MapperFeature.FIX_FIELD_NAME_UPPER_CASE_PREFIX.
Feature is disabled by default in 2.20 (for backwards-compatibility); it will be enabled by default in 3.0. Enabling the feature will add logic to fix this specific discrepancy without need for annotations.

Important new feature: Binary (Packed) Vectors

One cool technique I wrote about a while ago (see “Super-fast Packed Base64 Vectors”) is an optimization to serialize vectors (usually float[] or double[]) as Base64-encoded Strings instead of simple JSON Arrays. This is much more efficient — surprisingly so — both wrt processing and content size (smaller and faster to encode/decode).

Given working prototype handlers, performance results, it seemed reasonable to add explicit support for this format; it did not happen for 2.19 but got in Jackson 2.20.

To enable support, you can either annotate specific Vector-valued properties:

public class BeanWithBinaryFloatVector {
  @JsonFormat(shape = JsonFormat.Shape.BINARY)
  public float[] vector;
}

or, configure globally:

ObjectMapper mapper = JsonMapper.builder()
  .withConfigOverride(float[].class,
    c -> c.setFormat(JsonFormat.Value.forShape(JsonFormat.Shape.BINARY))
  ).build();

and then this alternate JSON serialization will be used for writing (and accepted on reading).

Version scheme change: drop patch from jackson-annotations (2.20, NOT 2.20.0)

(and make Jackson 3.x use 2.x jackson-annotations!)

One change that has been planned for a long time is the dropping of unused (*) patch version from jackson-annotations: basically versions 2.18.0, 2.18.1 , 2.18.2, 2.18.3 and 2.18.4 are all identical. So we might as well just publish 2.18.
Originally this change was planned only for Jackson 3.0, to maximize versioning compatibility for users that assume all components use the exact same version and do not use jackson-bom.

But when we decided to change the plan so that Jackson 3.0 will continue to use 2.x annotations (**)— version 3.0, specifically depends on 2.20 of jackson-annotations — it was decided that dropping patch version needs to happen with 2.20.0 release.

So: both Jackson 2.20.x and 3.0.x will depend on jackson-annotations 2.20 . Similarly 2.21.x and 3.1.x will (likely) depend on jackson-annotations 2.21 (although theoretically it is possible 3.1.x could depend on 2.20 annotations if 2.21 is not released before 3.1 — we will see).

If above sounds complicated, don’t worry: jackson-databind defines annotation version needed — and more importantly jackson-bom can be used to specify fully compatible version set. So you should rarely need to manually indicate specific jackson-annotations version to use.

(*) Unused during normal times: in theory it is possible some critical problem could require use of patch indicator. This is a very rare occurrence.
(**) Why not go with new 3.0 version of jackson-annotations? JSTEP-1 explains reasoning — in short, this allows using same annotations with both Jackson 2.x and 3.x, making upgrade process bit smoother, avoiding need to duplicate annotations which was sometimes needed for Jackson 1.x -> 2.0 upgrade (and more importantly, eliminates one common source of errors; mismatching annotation package).

New Datatype module: jackson-datatype-hibernate7

Existing datatype support for Hibernate was extended slightly, by contributed Hibernate 7 module (jackson-datatype-hibernate7) registered the usual way:

<dependency>
    <groupId>com.fasterxml.jackson.datatype</groupId>
    <artifactId>jackson-datatype-hibernate7</artifactId>
    <version>2.20.0</version>
</dependency>

ObjectMapper mapper = JsonMapper.builder()
    .addModule(new Hibernate7Module()));
    .build();

SBOM Metadata Publishing — almost :-(

As per [JSTEP-14], Jackson artifacts (jars) are now (2.20+) built with SBOM metadata (what are SBOMs? Read here). Intent was to publish this metadata into Maven Central along with artifacts.

But it looks like https://repo1.maven.org/maven2/com/fasterxml/jackson/core/jackson-core/2.20.0/ does not have expected artifacts. :-(

Rats. It was working at some point… need to go and see what happened.

**EDIT**: looks like publishing worked for 3.0.0-rc4 (https://repo1.maven.org/maven2/tools/jackson/core/jackson-core/3.0.0-rc4/) but no longer for 3.0.0-rc5 (https://repo1.maven.org/maven2/tools/jackson/core/jackson-core/3.0.0-rc5/). Configuration was not changed wrt SBOM plug-in but publishing swiched to Sonatype Central from OSSRH. So something in the newer repository seems to block publishing. Oh well.

Other updated modules

As usual, many extension modules were improved as well. Without more details, here are most notable:

• jackson-jr (3 changes)
• CBOR (jackson-dataformat-cbor) (4 fixes)
• CSV (jackson-dataformat-csv) (3 fixes)
• Kotlin (jackson-module-kotlin) (5 fixes)

That’s All, Folks!

And now back to working on Yet Another 3.0.0 Release Candidate :)
(I last blogged about 3.0.0-rc4 )

So, it has been almost 4 weeks since 3.0.0-rc3 — partly since 2.19.0 was released between rc3 and rc4. So what are the additions in this pre-release version?

Use MethodHandle s for Reflection

The biggest internal change is the long-planned change to replace “classic” Reflection usage with newer MethodHandles (see [databind#2083]).
Ideally this:

1. Will be mostly invisible change to users (work the same or better as before)
2. Possibly improve performance

Unfortunately (2) does not seem to materialize immediately (at least with JDK 17/21), but we hope to squeeze some performance gains yet (stay tuned!)
But there is also hope that MethodHandles will work better with newer JDKs and access restrictions imposed — so this can be considered a bit of future proofing.

Still, what is really important is (1): things should “just work”. Getting early feedback on possible problems would be very useful — which is why it was good to finally get this change included in a release. Getting feature fully working — passing all unit tests of not just jackson-databind but also all official Jackson extension modules — took a while (initially feature was to be included in 3.0.0-rc3 but had to be postponed).
So let’s hope for the best this time around. :)

JSTEP-14: generate and publish SBOMs

Another new feature is the automatic generation of SBOMs (of “cyclonedx” variety). See JSTEP-14 for details.
Addition is a bit speculative as it was not actually requested by anyone (despite tons of articles about importance of Software supply chain hygieny there seems to be no actual push for this, for whatever reason), but since addition was very easy to do with Maven plugin (cyclonedx-maven-plugin)… why not?
Classifier chosen to be used is sbom-cyclonedx (see https://repo1.maven.org/maven2/tools/jackson/core/jackson-core/3.0.0-rc4/ for examples of json and xml variants) but it can be changed as necessary — there just seems to be very little standardization (which is a bit ironic).

If anyone finds SBOMs useful (in actuality or potentially), please let us know!

Defaults change: MapperFeature.DEFAULT_VIEW_INCLUSION

Most of feature (MapperFeature, DeserializationFeature, SerializationFeature etc) default changes have already been made and included in previous RCs. But one last (?) change was to switch MapperFeature.DEFAULT_VIEW_INCLUSION from enabled to disabled (see [databind#1484] for details)
This basically means that when View processing is active (View defined for ObjectReader or ObjectWriter), properties with no @JsonView annotation will by default be excluded instead of being included (previous default).

This is just the default, of course: if previous default worked well you just need to explicitly set it.

JsonNode: more methods for accessing as float, short

After big JsonNode “xxxValue(), asXxx() rewrite” (both adding methods like intValueOpt() and defining clear semantics for validation and conversions allowed for asInt()) there was desire to extend set of accessors from initial (int, long, double, string, boolean, decimal, bigInteger) with 2 more — float (32-bit) short (16-bit integer).
For both, only simple accessor (floatValue(), shortValue()) existed.

[databind#5138] extends these with the usual additions — floatValue(default), floatValueOpt(), asFloat(), asFloat(default), asFloatOpt() (and same for short ) — to give even more safe-and-convenient access to numeric JsonNode values.

Next Steps?

At this point, we are getting ever closer to actual 3.0.0 release (there is no strict target date; but it will happen in 2025 — hopefully sooner than later).

But so far one big missing thing has been feedback: there has been limited number of reports about problems — and due to vast number of changes included (check current 3.0.0 Release Notes!) it seems unlikely everything would “just work” with no problems.

It is of course true that pre-Release versions have been available for less than 2 months so far. But we really, really need test usage!
Big thank you to those of you who HAVE reported issues (hi Sébastien!) — and thanks in advance to everyone who will report issues (or just positive experiences).

There will definitely be at least one — and more likely 2 or 3 — RC release before the big 3.0.0. But time to help is now!

Big Unknown: Sonatype OSSRH closure in June 2025

One last thing: a potentially major speed bump is this:

OSSRH Sunset Announcement

which affects Jackson project (as well as about most if not all other Java OSS projects) — there may lots (or possible not?) of work, blood, sweat & tears in getting publishing to work with new setup, to be able to publish new versions to Maven Central.

Hopefully it will work smoothly. We’ll see…

Did I already say that…

WE COULD REALLY USE SOME HELP TESTING JACKSON 3.0?

:-)

If not, ^^^^^

Continuing quick pace of pre-release versions, Jackson 3.0.0-rc3 is out now, about 2 weeks after 3.0.0-rc2.

Highlights include:

• Finally fixed Gradle dependencies, metadata (I think!)
• Native JPMS support for 3 more modules — jackson-module-kotlin, jackson-datatype-javax-money, jackson-datatype-moneta — leaving jackson-module-scala as the one and only 3.x Jackson module without JPMS from module-info.java (and based on what I have read, it will remain so)
• Embedding formerly separate Java 8 Date/Time module (jackson-datatype-jsr310) into jackson-databind, similar to 2 previously merged Java 8 modules ( jackson-datatype-jdk8, jackson-module-parameter-names).

all of which were planned as things to include next. One other expected feature — “Replace core Reflection use with MethodHandles” — https://github.com/FasterXML/jackson-databind/pull/5046 — was initially merged but had to be reverted due to problems with datatype modules.
It will likely be included in 3.0.0-rc4.

No More jackson-datatype-jsr310 as separate module

Of this these, the inclusion of Java 8 Date/Time module is probably the most significant change: you no longer have to (or can) register this module — support for java.time types is built in jackson-databind.

Date/Time configuration unification: new DateTimeFeature

After embedding jackson-datatype-jsr310 , a follow-up change was made to create new DateTimeFeature to combine formerly separate configuration features from:

• JavaTimeFeature of Java 8 Date/Time module
• Date/time related DeserializationFeature s (see databind#5067)
• Date/time related SerializationFeature s (see databind#5066)

So now all basic on/off configuration for Date/Time value reading/writing will be configured using DateTimeFeature :

// Can configure Mapper default settings
ObjectMapper mapper = JsonMapper.builder()
   .enable(DateTimeFeature.WRITE_DATES_AS_TIMESTAMPS)
   .build();
// as well as per-call settings via ObjectReader/ObjectWriter
String json = mapper.writer()
   .with(DateTimeFeature.WRITE_DATES_WITH_CONTEXT_TIME_ZONE)
   .writeValueAsString(LocalDateTime.now());

Enum read/write unification: fold into existing EnumFeature

Similar to changes wrt DateTimeFeature, another refactoring was done for Enum configuration. EnumFeature was added back in Jackson 2.14, but there were existing DeserializationFeatures / SerializationFeatures that cannot be moved in Jackson 2.x due to backwards-compatibility constraints.

For 3.0:

• Enum-related DeserializationFeatures (see databind#5079)
• Enum-related SerializationFeatures (see databind#5080)

were folded into EnumFeature so similarly all simple Enum reading/writing configuration will now use this separate configuration feature set:

// Can configure Mapper default settings
ObjectMapper mapper = JsonMapper.builder()
   .enable(EnumFeature.WRITE_ENUMS_USING_TO_STRING)
   .build();
// as well as per-call settings via ObjectReader/ObjectWriter
String json = mapper.writer()
   .with(EnumFeature.WRITE_ENUMS_TO_LOWERCASE)
   .writeValueAsString(MyEnum.FIRST);

Next Steps?

So the next thing will be 3.0.0-rc4 — planning for which is on-going.

Now that we have a release candidate for Jackson 2.19 — 2.19.0-rc2 (*) — it’s time to have a look at what goodies will be included. As usual, the full 2.19 release notes contain detailed list of all the changes; here we’ll look at biggest items.

(*) there is no rc1 — we had a problem with release process that resulted in needing to skip that version.

2.19 Stats

2.19 development has taken almost 6 months since 2.18.0 release, and there are over 80 changes (new features, fixes) across all official Jackson components — a bit more than 2.18 (with about 60 changes). Still, this can once again be classified as a “minor minor release” — partly due to now concurrent development work for finalizing 3.0.0 release (see this blog post for more) — with few bigger features but plenty of bug fixes.
As a result it is expected fewer regressions than with 2.18.0 where there was a major property introspection rewrite.

New modules: jackson-datatype-javax-money, -moneta

There are two related new modules for handling JSR-354 (Java Money) data types:

• jackson-datatype-javax-money: for core Java Money data types
• jackson-datatype-moneta: for supporting extended types in JSR-354 reference implementation

Modules were added in jackson-datatypes-misc repo and are added using standard module registration mechanism

ObjectMapper mapper = JsonMapper.builder()
    .addModule(new JavaxMoneyModule())
    .addModule(new MonetaMoneyModule())
    .build();
String json = mapper.writeValueAsString(Money.of(29.95, "EUR"));

Most-Wanted feature: Support for @JsonWrapped with @JsonCreator

One particularly highly voted-for issue — [databind#1467] — was implemented for 2.19.
This basically (finally!) allows using of @JsonWrapped with @JsonCreator like so:

public record Point(int x, int y) { }

public class Rectangle {
  private final Point origin;
  private int width, height;
  
  @JsonCreator
  public Rectangle(@JsonProperty("origin") @JsonUnwrapped Point origin,
     int width, int height) {
    this.origin = origin;
    this.width = width;
    this.height = height;
  }
  public Point getOrigin() { return origin; }
  public int getWidth() { return width; }
  public int getHeight() { return height; }
}

This is particularly important for Java Record types which cannot have fields or setters; now @JsonUnwrapped can be used for Record types.
(same is true for immutable types in Kotlin and Scala)

JsonNode functionality improvements

JsonNode (Tree Model) got a few additional methods added, to support Java 8 Stream and Optional types:

• [databind#2145]: Add optional(String) (Object nodes) and optional(int) (Array nodes) to complement existing get() and path() methods: both return Optional<JsonNode> with expected semantics (non-empty Optional if there is matching Property value/Array element; Optional.empty() if not)
• [databind#4863]: Add basic Stream support: JsonNode.valueStream() for iterating over Object property values and Array elements, JsonNode.propertyStream() for iterating over Object properties (name/value pairs) and JsonNode.forEachEntry(BiConsumer<String, JsonNode>) for alternative way to iterate over Object properties.
• [databind#4867]: Add JsonNode.asOptional() for essentially wrapping given JsonNode as Optional<JsonNode>— except for MissingNode which will become Optional.empty().
• [databind#4955]: Add 2 remove methods in ContainerNode (that is, for ArrayNode and ObjectNode which are 2 implementations): removeIf(Predicate<? super JsonNode>) for general purpose removal of Array elements and Object property values, and removeNulls() as a convenience short-cut for removing NullNode s from Arrays or Objects.

Global default EnumNamingStrategy

Assigning naming strategy for “non-standard” Enums (ones where in-Java ALL_UPPER names need to map different in-JSON (external) convention) has been possible for a while using @EnumNaming annotation like so:

@EnumNaming(EnumNamingStrategies.LowerCamelCaseStrategy.class)
static enum EnumFlavorB {
  PEANUT_BUTTER, SALTED_CARAMEL;
}
// in JSON now serialized as "peanutButter" and "saltedCaramel"

but until now there has not been any way to globally specify default naming convention (so default is “use Enum.name() as-is”) in case all (or most) your Enum types use different convention.

With [databind#4674] it is now possible to specify different default Enum naming strategy

ObjectMapper mapper = JsonMapper.builder()
  .enumNamingStrategy(EnumNamingStrategies.LowerCamelCaseStrategy.INSTANCE)
  .build();

which in turn may be overridden by @EnumNaming annotation on class.

Most Improved Modules: Avro, Java 8 date/time, Kotlin

In addition to above set of a dozen changes (all in jackson-databind), what else is changing? Majority of Jackson components had at least one change (see 2.19 Release Notes for details) but most noteworthy appear to be:

• jackson-core (streaming): 7 fixes (2 for JsonPointer handling)
• Data format modules in general, but Avro data format module (jackson-dataformat-avro) in particular: 5 fixes/improvements to Schema generation, Logical type handling
  (3 other format modules — CSV, XML, YAML — each had 2 fixes)
• Java 8 date/time module (jackson-datatype-jsr310): 4 fixes (2 for deserialization, 1 for round-tripping (ser + deser) and 1 for performance optimization)
• Kotlin module (jackson-module-kotlin): 15 changes!

What’s Next?

The plan is to release 2.19.0 soon, start 2.20 branch ((re)named as 2.x as per JSTEP-12), but focus even more on getting 3.0.0 ready for release.
Which reminds me that I need to write a bit about 3.0.0-rc3 that was also released recently.

One driver for RC2 was a reported Gradle dependency problem in RC1 — but unfortunately turns out this was only partially resolved (see here for follow-up). So (some?) Gradle users may need to wait until RC3 (I am not 100% sure if there is a work-around).

But aside from this unfortunate problem, there are 3 updates in RC2 (over RC1) to consider.

1. Remove need to use @JsonSubTypes for Sealed Classes

One useful improvement in JDK 17 (the baseline for Jackson 3) is thing called “Sealed Classes” (see Baeldung’s article for explanation if not familiar). With regular classes, polymorphic handling with type names requires use of not only @JsonTypeInfo in the base class, but also adding references to sub-classes using either ObjectMapper.registerSubtypes() or (more commonly) @JsonSubTypes annotation like so:

    @JsonTypeInfo(use=JsonTypeInfo.Id.NAME, include=As.PROPERTY, property="type")
    @JsonSubTypes({ @JsonSubTypes.Type(ImplX.class),
        @JsonSubTypes.Type(ImplY.class),
        @JsonSubTypes.Type(ImplZ.class)
    })
    abstract class BaseX { }

but with sealed classes and Jackson 3.0.0-rc2, you only need @JsonTypeInfo as marker (and definition of which type id to use):

@JsonTypeInfo(use=JsonTypeInfo.Id.NAME, include=As.PROPERTY, property="type")
abstract sealed class BaseX permits ImplX, ImplY, ImplZ { }

which works pretty well as sub-type definitions are required for sealed classes anyway — and you no longer can accidentally forget them.

2. Extended Accessors for JsonNode

One of bigger efforts with 3.0 has been JSTEP-3 — improvements to Jackson Tree Model, that is, to JsonNode and its subtypes. There have been quite a few actual smaller improvements (see Javadocs for 3.0.0-rc2 as well as JSTEP-3), but there was one last bigger task left: unification and extension of “xxxValue() / asXxx()” accessors. Unification means making accessors work uniformly along same rules (for numbers, checking that value fits range; that specific coercions are similarly allowed/disallowed); and extensions means adding all variants similarly. Some of the work is just making use of other additions — for example, now that JacksonExceptions are unchecked, a new exception type JsonNodeException may be thrown by accessors in problem cases; something not possible to change in 2.x (for backwards-compatibility).

The last part of this unification/extension was implemented via [databind#5003] and [databind#5034], adding a set of accessors for following types:

• int / long / BigInteger
• double / BigDecimal
• String
• boolean

There are 6 now different accessors for each of types listed, following pattern shown here for int accessors:

• int intValue(): returns int if (and only if) node contains Number that can be expressed as 32-bit Java int ; if not, will throw JsonNodeException.
  Valid JSON values would include 32 (regular integer that fits in range), 5.0 (number with empty fraction), 7.01E3 (scientific-notation but still integer). Invalid values would be Strings (“abc”, “10”), Booleans, Numbers with non-empty fractions (2.57), numbers outside 32-bit int range (1.0E100) and so on.
• int intValue(int defaultValue): Same as intValue() for valid int values, but for non-valid will return defaultValue instead of throwing JsonNodeException
• OptionalInt intValueOpt(): Same as intValue() (except for return type) but instead of throwing JsonNodeException returns OptionalInt.empty() for non-valid node values
• int asInt(): Similar to intValue() if we have valid integral number (returned as-is), but will allow additional coercion from some representations.
  Specifically will allow “Stringified” numbers (so String "137" would be returned as int value of 137 ). For other value types, other coercions allowed (for boolean , integral values accepted).
  Will thrown a JsonNodeException if none of coercions applicable
• int asInt(int defaultValue): Same as asInt() but if coercions fail, will return defaultValue instead of throwing JsonNodeException.
• OptionalInt asIntOpt(): Similar to asInt() (except for return type) but if coercions fail, will return OptionalInt.empty() instead of throwing JsonNodeException.

Whoa! That’s quite a few methods added. Beyond this extensive set of accessors, there are a few supporting typed accessors (pre-existing but improved):

• binaryValue() for both native Binary values (for formats that support them — Avro, CBOR, Protobuf, Smile) and Base64-encoded String values (JSON and other textual formats)
• floatValue() for 32-bit Java float (no coercions, regular type and range checks)
• numberValue() for accessing any of numeric types as its natural Number representation (no coercions, no range checks needed)
• shortValue() for 16-bit Java short s (no coercions, regular type and range checks)

Feedback wrt validation rules, ergonomics would be much appreciated.

3. Fix to getter/setter naming rules (no detecting island() :) )

And last & probably the least, [databind#2882] was fixed for 3.0.0-rc2 and following methods no longer infer properties:

public interface Beano {
  // Used to produce "_value"; now ignored unless annotated
  public int get_value();
  // Used to produce "land"; - "" -
  public boolean island();
  // Would be expected to set property named "ter"
  public void setter(int x);
}

which should remove occasional odd cases of “where did THAT come from?” when serializing POJOs.

4. Towards 3.0.0-RC3

And the next step is releasing RC3. The plan is for it to:

• Finally fix Gradle dependency issue (… but we do need your help to verify!)
• Probably merge “Java 8 date/time” module (jackson-datatype-jsr310) in jackson-databind (one less module to have to register) — https://github.com/FasterXML/jackson-databind/pull/5032
• Replace core Reflection use with MethodHandles — https://github.com/FasterXML/jackson-databind/pull/5046

When is that? Hopefully within next 2 weeks or so.

Happy Coding & Download with Care. :)