Towards Jackson 3: on 3.0.0-rc9

(and a bit on rc5, rc6, rc7 and c8)

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. :)