Jackson 3.0.0 JDK baseline: JDK 17 or JDK 21

[cowtowncoder]

(part of #72 uber-Discussion)

(note: actual issue for work at: FasterXML/jackson-databind#4820 -- will be modified based on results of discussion here)

For Jackson 3.0.0 we will be raising minimum JDK baseline required from Java 8 to a later version.
Version to use should be a Long-Term Support (LTS) version.

But which one? Strongest candidates as of now seem either 17 (has Records) or 21 (latest LTS).
So let's try to figure out which of these 2 is preferred.

[cowtowncoder]

Also: if you would like to explain votes for/against these versions, feel free to leave a comment or vote for an existing comment.

[stickfigure]

My rationale for 21: By the time Jackson 3.0 comes into common use (ie, the baseline for Spring), Java 21 will already be antique. No need to sandbag.

[yawkat]

My vote is 17. The reason is that while 11->17 has valuable upgrades for API design (records and sealed classes), the benefit for going 17->21 is fairly minor, especially for a library like jackson that does not deal with virtual threads.

[cowtowncoder]

Good points wrt features, existence of which (in 17) make life easier for Jackson. But there not being many b/w 17 and 21.

[sdeleuze]

My vote is for a Java 17 baseline for multiple reasons. It would allow Spring Framework 7 which has a Java 17 baseline to switch to Jackson 3 (see related issue) regardless of the Java version used. Also, Java 17 is the baseline chosen by major part of the ecosystem (Jakarta, Spring) and the next LTS Java 25 will be very close to be released when Jackson 3 will be out (I think) and on Spring side we will push for its adoption. So supporting a Java 17 baseline for lowering the entry bar while focusing in Java 25 LTS for most users concrete usage is IMO the sweet spot. I expect Java 21 adoption to quickly fall once 25 is released given it lack of a lot of efficiency features (better virtual thread by removing most remaining thread pinning for example).

[JooHyukKim]

My vote is 17 as well. A lot of framework/library depends on Jackson and they mostly have jdk 17 baseline as their latest major version.

[rikkarth]

My vote goes for 17 under the premise that industry standards, specially when it comes to Java don't move this fast.

I understand and personally would even agree with moving to 21 to push the industry up, but my experience is that companies almost always play it safe and decide to go for a different library instead, in some cases even fork it.

I think moving to 17 is a good common ground.

[cowtowncoder]

Right, baseline requirement increase for libraries like Jackson may proceed much more slowly than adoption of JDKs by applications, "end users".

[scrobbleme]

+1 for JDK 17.

A lot of applications are not always updated... i.e. the whole Atlassian stack. They are very slow adapting to newer versions, and Java 17 is currently the lowest supported Java version over there. (still have to support Java 8 as many customers are still not updated to 17)

Personally, I would like to see faster pace too... maybe already plan a 4.x with 21+ support.

[cowtowncoder]

TBH, making major version upgrade for Jackson is a very big undertaking so expecting new major version for 21 is probably not going to be realistic (2.x has been going on for over 10 years, just as reference).
However, it is possible to support things later JDKs provide similar to how Jackson 2.x supports many post-JDK-8 features (from module info to Records).
So choosing Java 17 as baseline need not make Java 21 support significantly harder.

[cowtowncoder]

Interesting, looks like there is more support keeping baseline at JDK 17 than I expected. Glad I created the poll.
But let's keep votes coming to see if consensus builds.

[maxandersen]

(I commented on FasterXML/jackson-databind#4820 (comment) which i'll repeat here)

Go for 17 please otherwise Quarkus, spring and lots of others will be stuck on older Jackson and we'll be all stuck maintaining old code.

Unless you know of some specific feature in java 21 that Jackson just can't function without and not support from Java 17 then please go for 17. And even if you know of some Java 21 specific feature - do tell as we are many that know how to support Java 21 features while still have main baseline on Java 17 :)

[yawkat]

To be honest, we'll probably have to maintain jackson 2 compatibility for quite a while anyway. In our case (Micronaut FW), the major release that will use jackson 3 as baseline is still some time away and will probably use java >=21 as baseline.

But I agree it's safer to stick with 17 in jackson for downstream frameworks.

[cowtowncoder]

Yes, there is every reason to believe that Jackson 2.x will (need to be) maintained for a long time.
More so than what happened with 1.x->2.0 transition.
But the baseline should be such that we have somewhat maximal potential adoption of 3.0 since this is the biggest concern I have (low adoption). To that end it definitely feels that Java 17 is better baseline.

There are PRs to increase baseline to 17 and we may proceed with those soon. But without yet committing to that as THE baseline -- just as the likely one.

Put another way, we can keep the discussion going but not be blocked by it (nor needing to force the resolution yet).

[JonathanGiles]

+1 to JDK 17. It feels like the safe landing spot for libraries transitioning out from the tyranny of JDK 8 baseline. Anything more than that feels too soon, and as mentioned by others, appears to yield less than what is received from the JDK 8 -> JDK 17 jump.

[lobaorn]

I voted for 21 so that 17 does not win by a landslide, all the arguments in favor make it the best decision. My feeling is that the only thing that will truly make a new baseline, like Java 8 did, is when Value Classes/Valhalla is finally available on a "LTS" version. I suppose until then, Jackson should be in a 3.X version with 17+ compatibility. And when the time comes, maybe a 4.X with 29+ compatibility.

[cowtowncoder]

Thank you for sharing you rationale @lobaorn !

[lobaorn]

Thank you for engaging on the community. Another feature that could/will be useful for Jackson is the (Un)Marshalling, presented by Victor Klang here: https://youtu.be/mIbA2ymCWDs but I suppose that either it will come alongside Valhala features or after them. Nevertheless, the future is bright :)

[cowtowncoder]

Ok quite a ways out then. Will watch to have an idea what is coming :)
(thank you for sharing)

ps. Funnily enough, Jackson was mentioned somewhere around 6 minutes (briefly)

[lobaorn]

From my pov, Marshalling will mean for Jackson what the Classfile API means for Byte Buddy: a "better" or at least "simpler/official" abstraction to build upon.

[cowtowncoder]

It was interesting to note that improvements wrt Record serialization (that exist, not the thing about Patterns) are what Jackson uses from Records as well (deser going via constructors etc).

[bringyou]

I'll pick 21. In my opinion, JDK21 will have a lifespan as long as JDK8, because it offers many features, e.g. pattern matching, record class, virtual threads, ZGC. Picking JDK21 can keep the project baseline unchanged for a long time.

[sdeleuze]

Feel free to disagree, but with key parts of the JVM ecosystem having already chosen a Java 17 baseline, and with Java 21 not having key enhancements like fixing the thread pinning issue with Virtual Threads or Project Leyden AOT cache that Java 25 will have, it is IMO very unlikely that Java 21 will be a strong baseline.

[lobaorn]

Agreed @sdeleuze , and the benefits of 25 may not be sufficient for many. I suppose that 29 will move the needle as baseline, due to the incoming jeps of Leyden, Amber and Loom. And obviously, whenever those of Valhala are available, a new baseline is certain. But I am unsure if it will come by 29 (3y) or 33 (5y).

[scrobbleme]

A compromise could be to go with 17 first, and already announce 21 for "two years" later, and target a 3.2 or later with it...

[cowtowncoder]

And as always, note that just because baseline was, say, 17, does not mean Jackson cannot support features present in later JDKs. It is bit more work for sure, but has worked acceptably wrt Jackson 2.x, supporting Records (from JDK 14).

It does seem to me that the Java Community at large is coming round to Java 8 -> 17 being the usual migration step for libraries and frameworks -- end applications can (and generally do) jump to later versions, but libraries lower in the stack need to be more cautious.

I will leave this open, but I do think we are reaching consensus here.