Restarting this discussion, hoping someone else would like to add a comment.
Just like JAXB can not hide it's annotations, we can not hide the
Jackson annotations, but we can hide any call to a jackson specific api
(ObjectMapper).
A few more infos :
- Jackson is ranked #11 on the main maven repository
- yasson is ranked #1876
If we look at JSON specific libraries :
- https://mvnrepository.com/open-source/json-libraries
Jackson holds the 5 out of 6 of the top ranks.
Even if it gets replaced by something else, gson, yasson, futur java
serializing, it will not happen before a decade.
And when that happens, if it happens, we will plan for a migration.
Johann
Le 11/09/2025 à 11:45, Martin Desruisseaux a écrit :
Hello Johann
The Coverage JSON module is in the incubator group of modules, so I
guess that it can change its dependency to the JSON library as it
wishes. This choice would have no impact on the core modules
(referencing, etc.) currently included in releases. But I suggest to
keep in mind that a Jackson dependency may be only temporary, so it
may be safer to not depend too much on Jackson-specific API. In a
larger picture which includes both JSON and XML, there will be major
changes in the way that we serialize objects in Java. The general
direction can be viewed here:
https://www.youtube.com/watch?v=R8Xubleffr8
This is not necessarily in opposition with Jackson. Integration with
Jackson is discussed around 32 minutes in the video. We can not yet
implement what is described in the video, but we should keep in mind
that the use of Jackson would be hidden. Therefore, I guess that using
Jackson is okay if that dependency does not appear in public API and
does not appear in core modules.
Martin
Le 11/09/2025 à 10:29, Johann Sorel a écrit :
Hello,
I would like to start working on GeoJSON (and it's extensions
json-fg, dggrs, ...) but before that I would like to talk about the
current choice of JSON library made.
So far we have the CoverageJSON module (which I wrote), this module
use Jakarta JSON-B v3.
It works but JSON-B has not been adopted by the community.
The first version of JSON-B (JSR 367) was out in 2017. after the
creation of JackartaEE by Eclipse (when JavaEE stopped), two new
versions of JSON-B came out.
But even today, we only have Eclipse Yasson (the reference
implementation) which exist to promote JSON-B.
The truth is the Jackson-json library exist since 2016 and has a full
api very similar to json-p and json-b.
the project is very active and has large support for other json-like
formats such as : avro, cbor, ion, protobuf, smile, ... and more...
By looking at maven repo of the two projects :
https://mvnrepository.com/artifact/org.eclipse/yasson
https://mvnrepository.com/artifact/com.fasterxml.jackson.core/jackson-databind
We can see jackson is clearly the winner.
My feeling is we are going the wrong way, I understand sticking to
JRE API and big project API is a security.
But even if the community wakes up and build around json-b starting
today, it would take a decade before it catch up with jackson-json.
Does anyone have objections to switching to jackson-json ?
Johann Sorel
