jackson-databind supporting both 2.x & 3.x simultaneously?

[edeandrea]

If I'm building a library that wants to support jackson-databind both versions 2.x & 3.x, is that possible? I don't want my library to be prescriptive to a jackson version.

For now, my library uses JsonDeserialize, JsonPOJOBuilder, and JsonMapper.

Could my library have a compileOnly(Gradle)/provided (Maven) scoped dependency on both versions?

[cowtowncoder]

@edeandrea Yes, in the sense that 2.x and 3.x live in different namespaces (Java packages: com.fasterxml.jackson for 2.x vs tools.jackson for 3.x). And both use 2.x annotations.

But I guess what exactly do you mean supporting both.

For value classes that just use annotations from jackson-annotations (2.20) this is easy; both 2.x and 3.x support same set. But otherwise code needs to use one or the other.

[edeandrea]

For value classes that just use annotations from jackson-annotations (2.20) this is easy; both 2.x and 3.x support same set. But otherwise code needs to use one or the other.

Yes that is true. In my case I need to use JsonMapper (or ObjectMapper), but I want to support usage in existing frameworks (like Quarkus & Spring, which currently use Jackson 2.x) as well as pure-java using Jackson 3. I think I've figured out a way to do it using runtime classpath detection.

As @pjfanning mentions here the solution isn't bullet-proof, because the end user will need to bring in the appropriate jackson-databind dependencies they wish to use (or if using Quarkus or Spring, Quarkus or Spring will do it for them). I just used good old Java inheritance to stub out the pieces that actually need jackson-databind and contained it into a single class, then providing 2 implementations of the class, instantiated by a factory that does a classpath check (see docling-project/docling-java#27 if you're interested).

[pjfanning]

Yes. It is possible to have optional or provided dependencies on both Jackson 2 and Jackson 3 libs because they use different package names.
If you use an API method that was added in 2.20 then users will get NoSuchMethodErrors if they use jars from an older version of 2.x.
Since your pom file will only have an optional or provided dependency, the users will likely not be warned by their build tool that they are using an incompatible Jackson jar. There are ways to manage these risks through documentation, etc.