Personally, I do not see any problem to ship Jackson dependency in an SIS module working with JSON data, even if this module is a core one (endorsed).
Jackson is already the de facto industry standard, used both by Spring MVC [1] and Quarkus [2] as their default json codec (I suspect Micronaut to also use Jackson by default, but I cannot find any clear documentation about it, and I do not know micronaut well enough). If we look at Github dependency graph, it looks like there are already a lot of Apache projects depending on it [3]. Regards, References : - [1] Spring MVC documentation states it uses Jackson 3 as default Json codec : https://docs.spring.io/spring-boot/how-to/spring-mvc.html - [2] Quarkus documentation instructs to use Jackson as default JSON provider : https://quarkus.io/guides/rest-json#creating-the-maven-project - [3] Github dependcy graph: Jackson v2 dependents in apache projects : https://github.com/FasterXML/jackson-databind/network/dependents?owner=apache&package_id=UGFja2FnZS0xODAwMjQ3MjM%3D Le mer. 22 juil. 2026 à 11:04, Johann Sorel via dev <[email protected]> a écrit : > > 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
