Path to 3.0.0-rc4

[cowtowncoder]

Goal of this Discussion

This Discussion is continuation/part of Path to 3.0.0, digging into details of what should go in the fourth release candidate -- 3.0.0-rc4 -- of Jackson 3.
You may want to check out Path to 3.0.0-rc3 for background.

Note that significant part of actual changes will be based on feedback/bug-reports for 3.0.0-rc3: this document focuses more on more strategic/tactical things.

Goals for 3.0.0-rc4

Complete in-progress JSTEPs

Most JSTEPs are either complete or mostly complete. Of latter, let's try to close on:

• JSTEP-2: Jackson 3.0 Default Settings
  • Default changes to core (streaming, databind) components complete
  • Changes to jackson-dataformat-xml complete
  • Need to go over rest of modules to see if change desired

Continue implementing JSTEP-5

One JSTEP -- JSTEP-5 -- Unify Date/Time handling -- is in initial implementation stage.
It is a long-term challenge and we have one chance to significantly improve things.

Note: "Java 8 date/time" (jackson-datatype-jsr310) module was merged in jackson-databind for 3.0.0-rc3, and new DateTimeFeature was created to contain:

• Former JavaTimeFeature features jsr310 module had
• All date/time - related DeserializationFeatures / SerializationFeatures of jackson-databind

Continue with JSTEP-12

JSTEP-12 -- Rename head branches -- has been started, so all master branches were renamed as 3.x, along with CI changes.

The second part -- creating similarly named and behaving 2.x branch -- needs to wait until 2.19.0 is released (well doesn't have to, but makes most sense): once this happens, can complete this JSTEP. This should happen before 3.0.0-rc4 is released.

New JSTEP(s)?

JSTEP-13 -- LTS versions/branches for Jackson. Not specific to 3.0, but something to tackle soon, esp. wrt 2.x versions.

Issues to fix, PRs to merge

Any?

MethodHandles over Reflection

An attempt was earlier made but had to be reverted. We do have

• PR databind#5090

for another attempt and will probably try to get that merged.

Other?

What else do we want to achieve?

[cowtowncoder]

@JooHyukKim @pjfanning @k163377 @yawkat 3.0.0-rc3 released, it is time to consider the next milestone, rc4.

[JooHyukKim]

I havent found time to get something going for JSTEP-5 yet.

From what I read, what I think could be the highest priority would be unifying ‘@jsonformat’ behavior. But how do the type-deserializer/serializer currently differ? Need to find out

[cowtowncoder]

Right. I hope unification of formerly separated features from Ser/DeserFeature/JavaTimeFeature into DateTimeFeature might help slightly too.

Going through open issues for JSR-310 module (https://github.com/FasterXML/jackson-modules-java8/issues) could help, maybe also Joda (https://github.com/FasterXML/jackson-datatype-joda/issues). For latter, there are only 4 open issues but 3 seem relevant wrt JSTEP-5.

[JooHyukKim]

While writing JSTEP‑5 tests I ran into a few concerns:

1. Avoid breaking existing systems

• Provide a compatibility switch (or per‑type @JsonFormat) so services that still expect epoch‑millis or array timestamps keep working.

2. Handle historical data

• Many teams have years of JSON stored in databases or logs.
• Should the new Jackson auto‑detect old formats, or should we ship a bulk‑conversion tool?

3. Scope the effort

I am now thinking if focusing on below two would make more sense?

1. Refactor for easier future fixes.
2. Then fix the actual issues.

[cowtowncoder]

Important questions. One thing worth noting is that whereas on serialization format must be selected into one specific Shape (cannot be "String or Number"), on deserialization we typically allow multiple Shape alternatives.
This is not true for all cases (f.ex resolution of number without unit, milli-/micro-/nano-seconds), but where it is, we have bit more room for changes.

I agree that we should try not to break compatibility unless necessary. But it comes down to judgment call.

I think these must be decided on case-by-case basis: so creating issues for changes considered makes sense.

My main concern in postponing changes is that 3.0 is the most viable point of backwards-compatibility breakage: our one chance.

I think going with scope (3) makes sense but so that priority is on fixes that can only be done in 3.0. Anything that is fixable in 2.x (or later 3.x) is not as important.
I wish I could give more guidance, but priorization is, too, easier to evaluate on case-by-case basis (beyond my very general guideline).

[sdeleuze]

I am currently adding support for Jackson 3 in Spring Framework 7 via spring-projects/spring-framework#33798.

I have created a bunch of issues with some potential bug or enhancement that would help Spring support if integrated in upcoming RC:

• Jackson 3 regression: writeValue with a JsonGenerator does not take in account the PrettyPrinter jackson-databind#5109
• Add missing ObjectMapper#createNonBlockingByteBufferParser() method jackson-databind#5110 (fixed)
• Improve support for deserializing from TokenBuffer (f.ex for content buffered for non-blocking parsing) jackson-databind#5111
• Add a MapperBuilder#findAndAddModules(ClassLoader) variant jackson-databind#5112 (fixed)

[cowtowncoder]

All 4 issues @sdeleuze referenced were addressed by 3.0.0-rc4.

[cowtowncoder]

3.0.0-rc4 was released today, 10-May-2025, closing.

Created new one for rc5: #86