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
