Release 3.3.0, non-LTS, no Release Candidates: focus; Vulns, Performance

[cowtowncoder]

We are getting close to wanting to release new Jackson 3.x minor version, 3.3: partly this is simply due to accumulation of changes (128 already! Not far from 160 for 3.2); and partly to release before Sonatype Publish limits kick in (if we can do that).

Changes accumulated so far can be seen here: https://github.com/FasterXML/jackson/wiki/Jackson-Release-3.3

LTS (Long-Term Support) version: no

Since Jackson 3.1. was an LTS, I think we should have at least one more non-LTS one; 3.4 might be the next LTS.

Release Candidate(s) (RCs): no

Going forward, I think we should only do RC(s) for LTS versions, unless there are some risky changes.
So defaulting to no RCs for non-LTS.

Dependencies

We will want to keep 2.x and 3.x synced for now, so 2.23.0 release of Jackson 2.x should be pushed at around same time -- but due to coupling with jackson-annotations (for which we push 2.23), 2.x needs to go first.

Note: although 2.23 has only 24 fixes (https://github.com/FasterXML/jackson/wiki/Jackson-Release-2.23), many are worthwhile so this is not a useless release either.
It should also not become an LTS (2.21 was).

Also: we probably would want to release full set of supported branches right before 3.3.0 / 2.23.0:

• 2.18.12 / 2.21.8 / 2.22.4
• 3.1.8 / 3.2.4

which contain multiple CVE fixes already (and might accumulate couple more before release)

Timeline

At this point, I would suggest Friday, October 30, 2026 as the target for 2.23.0 / 3.3.0 releases.
From that, we need to release 5 (!) sets of patches before that; and since I mostly have time on Fridays and weekends, these would be targeted for release on Friday, October 23, 2026.
This would gives us about week and a half to finish up work.
This is tight but we can start with it as a Stretch Goal. If it does not work we can extend timeline as necessary; Sonatype publishing limits may need to be resolved but there is no need to rush if things are not ready for release.

Issues to Include/Exclude, Prioritize; labels

Priorities: Vulnerabilities, Performance

As usual, we should try to tackle as many of reported (as GHSA) issues as possible.

Second priority category for this version is, I think, Performance -- we have a few good PRs for jackson-core and various data format backends; so let's focus on gettings those in.

Third category -- if time allows -- are low-risk bug fixes ("low-hanging fruit"); favoring number of fixes over tackling more complex things for which more time allows for thorough review process.

Exclude

At this point, we should try to limit riskier changes; especially things that need fundamental changes and/or major refactoring. This includes at this point:

• @JacksonInject handling fixes
• (possibly) any of @JsonView fixes

Tagging (labels)

We should use Github Labels to indicate priorization, like so:

• To indicate things that we want to include in 3.3.0 (and maybe 2.23.0, depending), use label 3.3 (or 2.23)
• To indicate things that we don't think can go in 3.3.0, but should be tackled soon after, use label 3.4 (even if backport to 2.x planned)
• To indicate things that we don't think can go in 3.3.0 and that are not urgent, use label 3.x (NOTE: this does NOT mean they could not be included in 3.4; just that there is no urgency)

NOTE: if labels are missing for some repos, feel free to create if you have access; if not, add a comment here.
Similarly if you cannot apply labels, add a comment on issue/PR tagging me and I can add label.

[cowtowncoder]

/cc @pjfanning @JooHyukKim @k163377 @stevenschlansker @yawkat @sdeleuze

Note: anyone tagged interested in helping with GHSA (vuln submissions) but does not yet have access, DM/email me and I can add you to relevant role (see https://github.com/FasterXML/jackson-databind/security/advisories to see if you do have access).

Similarly wrt access to edit other relevant things; Wikis, READMEs; if I can give access, I will.

[JooHyukKim]

Yes, I will see if I can pull off addressing one or two issues off vuln reports!

[cowtowncoder]

I think one helpful thing is simply adding links to GHSAs open, PRs for the same; keeping track is getting challenging.
And also pointing out those GHSA submissions that do not appear to be actual security vulnerabilities.

[yawkat]

Yea there are too many GHSAs to keep track of nowadays. I've had good success using AI to keep track of GHSAs though (validity, fix status, merge status, metadata, etc). It's helped me deal with the GHSA flood in netty and micronaut. I'll spend some time today on the jackson GHSAs

[cowtowncoder]

(Note: everyone with access should update this as necessary, don't be shy -- or if you can't, add a comment and I'll update)

TODO list: things to try to get in

Core

• #1765: async-parser, hex parsing -- [DONE]
  • https://github.com/FasterXML/jackson-core/security/advisories/GHSA-vvjm-vc27-799r

Databind

Vulns:

• #6254 -- Validating polymorphic types
  • https://github.com/FasterXML/jackson-databind/security/advisories/GHSA-x3x8-94h3-f4g3

Other:

• Limit regex pattern length at deser time jackson-databind#6130 -- Regex deser hardening
• Deserializing empty Locale map keys fails jackson-databind#6273 -- Locale regression --[DONE]

Data formats

Protobuf

Vulns:

• https://github.com/FasterXML/jackson-dataformats-binary/security/advisories/GHSA-fv7v-rrmh-4qcv -- DoS via Map<String, Int>, int length overflow
  • no PR yet

TOML

• Include zero seconds in TOML Java time output jackson-dataformats-text#759 -- TOML, Date/time values

Data types

jackson-datatypes-collections

• Add fastutil collection module: Add jackson-datatype-fastutil module (#38) jackson-datatypes-collections#249
• Guava Multiset change: Serialize Multiset as list of element/count entries (#2) jackson-datatypes-collections#272

Other Modules

• Blackbird rewrite for performance: Blackbird: ClassFile generation of unrolled codec class, optimize record / builder / field jackson-modules-base#359
  • needs JDK 25, must document on https://github.com/FasterXML/jackson/wiki/Jackson-Release-3.3

[pjfanning]

Apologies but I'm on a train with just my phone but FasterXML/jackson-core#1764 is for a GHSA. I don't think it's anything more than a code improvement but probably worth getting in.

[pjfanning]

FasterXML/jackson-databind#6274 fixes a regression.

[pjfanning]

FasterXML/jackson-databind#6130 could be seen as an edge case that we need to harden.

[cowtowncoder]

https://github.com/FasterXML/jackson-databind/issues/6273 now merged.

[JooHyukKim]

Went through open issues/PRs again after the status update. Not on the TODO yet, but I think these need to be in 3.3.0:

• databind#6275 -> 3.2 regression, no response/PR yet: per-type NON_DEFAULT now drops explicit null over a non-null default, so it silently round-trips back to the default. Should be decided before 3.3 makes it the baseline (fix on 3.2 for 3.2.4)
• modules-base#359 -> besides the JDK 25 docs: its META-INF/services entry breaks findAndAddModules() for all modules on JDK 17–24 (UnsupportedClassVersionError aborts the ServiceLoader loop). Also needs a JDK 25 release build, otherwise Blackbird is silently skipped
• databind#5715 -> @JsonWrapped is already in annotations 2.23, which ships first. Either merge this or pull the annotation from 2.23 [REVERTED/DEFERRED]
• databind#6224 -> perf: with default 3.x settings the vanilla fast path is never used, so the nextNameMatchAndToken work already in 3.3 (core#1688, databind#6193) never actually runs
• core#1682 -> perf: +5–23% on string writes; adds protected API, so minor-only
• XML: #918, #921 -> escaped-name output changes, same area as #886/#895 already in 3.3; better to ship together than change it again in 3.4
• text#759 -> TOML 1.0 requires seconds in time values; output change, so minor-only (needs CLA)
• databind#6130 -> on the list, but default limit vs opt-in is still undecided; needs a call this week or it slips to 3.4

One more: databind#6260 (3.3) and #6261 (2.23) are new @JsonView features, so per the exclusion in the original post I'd move them to 3.4, unless you want them in.

[cowtowncoder]

Yes, need to decide on @JsonWrapped -- FasterXML/jackson-databind#5715 -- probably pull out, unless we can really clean up implementation.

EDIT: reverted jackson-annotations change, re-created PR for possibly inclusion in 2.24.

[cowtowncoder]

Deferred FasterXML/jackson-databind#6260; but will probably try to include FasterXML/jackson-databind#6261 [DONE]

[stevenschlansker]

FasterXML/jackson-modules-base#359 -> besides the JDK 25 docs: its META-INF/services entry breaks findAndAddModules() for all modules on JDK 17–24 (UnsupportedClassVersionError aborts the ServiceLoader loop). Also needs a JDK 25 release build, otherwise Blackbird is silently skipped

Thank you for catching this, I will evaluate and include fixes in the next iteration.