Jackson 3.0.0-rc4
(getting closer to 3.0.0 final)
So, it has been almost 4 weeks since 3.0.0-rc3 — partly since 2.19.0 was released between rc3 and rc4. So what are the additions in this pre-release version?
Use MethodHandle s for Reflection
The biggest internal change is the long-planned change to replace “classic” Reflection usage with newer MethodHandles (see [databind#2083]).
Ideally this:
- Will be mostly invisible change to users (work the same or better as before)
- Possibly improve performance
Unfortunately (2) does not seem to materialize immediately (at least with JDK 17/21), but we hope to squeeze some performance gains yet (stay tuned!)
But there is also hope that MethodHandles will work better with newer JDKs and access restrictions imposed — so this can be considered a bit of future proofing.
Still, what is really important is (1): things should “just work”. Getting early feedback on possible problems would be very useful — which is why it was good to finally get this change included in a release. Getting feature fully working — passing all unit tests of not just jackson-databind but also all official Jackson extension modules — took a while (initially feature was to be included in 3.0.0-rc3 but had to be postponed).
So let’s hope for the best this time around. :)
JSTEP-14: generate and publish SBOMs
Another new feature is the automatic generation of SBOMs (of “cyclonedx” variety). See JSTEP-14 for details.
Addition is a bit speculative as it was not actually requested by anyone (despite tons of articles about importance of Software supply chain hygieny there seems to be no actual push for this, for whatever reason), but since addition was very easy to do with Maven plugin (cyclonedx-maven-plugin)… why not?
Classifier chosen to be used is sbom-cyclonedx (see https://repo1.maven.org/maven2/tools/jackson/core/jackson-core/3.0.0-rc4/ for examples of json and xml variants) but it can be changed as necessary — there just seems to be very little standardization (which is a bit ironic).
If anyone finds SBOMs useful (in actuality or potentially), please let us know!
Defaults change: MapperFeature.DEFAULT_VIEW_INCLUSION
Most of feature (MapperFeature, DeserializationFeature, SerializationFeature etc) default changes have already been made and included in previous RCs. But one last (?) change was to switch MapperFeature.DEFAULT_VIEW_INCLUSION from enabled to disabled (see [databind#1484] for details)
This basically means that when View processing is active (View defined for ObjectReader or ObjectWriter), properties with no @JsonView annotation will by default be excluded instead of being included (previous default).
This is just the default, of course: if previous default worked well you just need to explicitly set it.
JsonNode: more methods for accessing as float, short
After big JsonNode “xxxValue(), asXxx() rewrite” (both adding methods like intValueOpt() and defining clear semantics for validation and conversions allowed for asInt()) there was desire to extend set of accessors from initial (int, long, double, string, boolean, decimal, bigInteger) with 2 more — float (32-bit) short (16-bit integer).
For both, only simple accessor (floatValue(), shortValue()) existed.
[databind#5138] extends these with the usual additions — floatValue(default), floatValueOpt(), asFloat(), asFloat(default), asFloatOpt() (and same for short ) — to give even more safe-and-convenient access to numeric JsonNode values.
Next Steps?
At this point, we are getting ever closer to actual 3.0.0 release (there is no strict target date; but it will happen in 2025 — hopefully sooner than later).
But so far one big missing thing has been feedback: there has been limited number of reports about problems — and due to vast number of changes included (check current 3.0.0 Release Notes!) it seems unlikely everything would “just work” with no problems.
It is of course true that pre-Release versions have been available for less than 2 months so far. But we really, really need test usage!
Big thank you to those of you who HAVE reported issues (hi Sébastien!) — and thanks in advance to everyone who will report issues (or just positive experiences).
There will definitely be at least one — and more likely 2 or 3 — RC release before the big 3.0.0. But time to help is now!
Big Unknown: Sonatype OSSRH closure in June 2025
One last thing: a potentially major speed bump is this:
which affects Jackson project (as well as about most if not all other Java OSS projects) — there may lots (or possible not?) of work, blood, sweat & tears in getting publishing to work with new setup, to be able to publish new versions to Maven Central.
Hopefully it will work smoothly. We’ll see…
Did I already say that…
WE COULD REALLY USE SOME HELP TESTING JACKSON 3.0?
:-)
If not, ^^^^^
