Progress towards Jackson 2.12 (ETA: October 2020)

9 views
Skip to first unread message

Tatu Saloranta

unread,
Aug 5, 2020, 12:21:05 AM8/5/20
to jacks...@googlegroups.com
Since I am going for a brief vacation, I thought I might send a quick
update on my plan for getting Jackson 2.12 ready for release.
My todo wiki page:

https://github.com/FasterXML/jackson-future-ideas/wiki/Jackson-Work-in-Progress

should be quite up-to-date and show specific things I plan to tackle.

The goal for 2.12 minor version was to combine the shorter development
cycle of 2.11 (about 6 months) with more ambitious features of 2.10
(took 2 years), specifically targeting "most wanted" features.
No changes are planned for JDK baseline or dependencies.

The Big features I think should be included in 2.12 include:

1. Ability to configure datatype coercions (implicit conversions in
case where JSON type does not have obvious natural mapping)
(https://github.com/FasterXML/jackson-databind/issues/2113)
2. Much improved XML module (duplicate-preserving `JsonNode`, mixed
content, fix most existing bugs) (multiple issues)
3. `@JsonIncludeProperties`!
(https://github.com/FasterXML/jackson-databind/issues/1296)
4. Improved 1-argument Creator detection
(https://github.com/FasterXML/jackson-databind/issues/1498)
5. Java 14 Record support

Of these, first three are complete: "CoercionConfig" and much improved
`jackson-dataformat-xml` were rather large undertakings (and former
requires more work to support by datatype modules); fortunately
Baptiste send an impressive PR to implement `@JsonIncludeProperties`.

This leaves last two items: for #5 there is a PR and I just need time
to think through smaller details, but the basic idea is sound.
And then I have to focus on getting #4 done: after
`@JsonIncludeProperties` it is probably the oldest "most wanted" issue
around, and while the "big introspection rewrite" is still planned for
Jackson 3.0, this should help with one specific edge case.

Now: my original stretch goal was to get 2.12.0 released some time in
September; this would require the release candidate(s) to be released
in late August or so. This may be bit tight scheduled, so more likely
release will not occur before October, but we'll see.

In the meantime, I have struggled mightily with:

https://github.com/FasterXML/jackson-databind/issues/2803

which is a rather gnarly fundamental problem with handling of cyclic
types with contextual deserializers. I think I now know how it is to
be addressed, but it will be tricky to implement.
There are also a few smaller likely must-have or
really-should-get-it-in features on Jackson W-I-P list.

Anyway, I hope above is of interest to some of you. Take care!

-+ Tatu +-

Tatu Saloranta

unread,
Sep 16, 2020, 7:27:06 PM9/16/20
to jacks...@googlegroups.com
Ok some updates.
At this point #5 -- Java 14 Record support is complete and assumed working.

I am now working on #4, adding interface/API, having implemented parts
of the feature.
Hoping to complete by the end of this week, which would allow RC by
end of September.

This leads to one practical question: naming of the first (and
possibly only) Release Candidate.
2.11.0.rc1 went smoothly and was useful in finding a couple of
defects, which was an encouraging result
compared to earlier RCs where there was less feedback.

But it uncovered one problem: while use of "rc" over "pr" was a good
change (former is handled by systems that
are aware of qualifiers; latter not), there seems to be a fundamental
problem with separator for last part, so that:

1. "2.11.0.rc1" is NOT recognized as special non-production by some
systems (esp. ones relying on strict SemVeer)
-- most importantly, Tidelift (libraries.io) considers this a
"real" release, which is unfortunate
2. "2.11.0-rc1" WOULD BE recognized by Tidelift et al but apparently
DOES NOT work as version for OSGi

It is possible there could be some magic to let "2.12.0-rc1" be used
as Maven version but translate it into "2.12.0.rc1"
for OSGi Manifest: if anyone has ideas of how to make Maven build do
that I am all ears.

But assuming that there is a choice to be made here where something
has to give, I am leaning towards sacrificing
OSGi compatibility of Release Candidates (real published versions
still working, of course), Tidelift
being a backer of Jackson project (and my having to do more metadata
maintenance work if qualifier isn't recognized).

So: my current plan is to change versioning to use

2.12.0-rc1

as the Release Candidate version for Maven release.

I am open to suggestions here and thought I'll share the current situation

-+ Tatu +-
Reply all
Reply to author
Forward
0 new messages