com.fasterxml.jackson.databind: Maven Coordinates, Modules, and Version Strategy

The string com.fasterxml.jackson.databind is a Java package name, not a Maven coordinate: the artifact you declare is com.fasterxml.jackson.core:jackson-databind, and confusing the two is the single most common reason a Jackson dependency "cannot be resolved". It is an understandable trap. Jackson's group IDs, package names, and module names overlap just enough to mislead, and because Jackson is the default JSON stack for Spring Boot, Quarkus, and half the JVM ecosystem, the confusion is universal. This guide fixes the coordinates once, maps the modules you actually need, and lays out a version strategy that keeps your builds consistent and your security scanner quiet.

The coordinates, stated plainly

The Jackson core trio lives under the com.fasterxml.jackson.core group ID:

<dependency>
  <groupId>com.fasterxml.jackson.core</groupId>
  <artifactId>jackson-databind</artifactId>
  <version>2.19.0</version>
</dependency>

That one artifact transitively brings the other two members of the trio:

• jackson-core — the streaming parser/generator (JsonParser, JsonGenerator)
• jackson-annotations — @JsonProperty, @JsonIgnore, and friends
• jackson-databind — ObjectMapper, the tree model, and the data-binding layer, whose classes live in the Java package com.fasterxml.jackson.databind

So: group com.fasterxml.jackson.core, artifact jackson-databind, package com.fasterxml.jackson.databind. Three different strings, one library. Gradle users, same coordinates:

implementation("com.fasterxml.jackson.core:jackson-databind:2.19.0")

If you searched for a jackson databind maven dependency and found snippets using com.fasterxml.jackson.databind as a group ID, they are wrong and will fail resolution; nothing is published under that group.

The module you almost certainly also need: jsr310

Out of the box, ObjectMapper does not know how to serialize java.time types sensibly. LocalDate, Instant, and ZonedDateTime either fail or serialize as ugly field-by-field objects. The fix is the JavaTimeModule, published as com.fasterxml.jackson.datatype:jackson-datatype-jsr310, note the different group ID, com.fasterxml.jackson.datatype, used for all datatype modules:

<dependency>
  <groupId>com.fasterxml.jackson.datatype</groupId>
  <artifactId>jackson-datatype-jsr310</artifactId>
</dependency>

ObjectMapper mapper = JsonMapper.builder()
    .addModule(new JavaTimeModule())
    .disable(SerializationFeature.WRITE_DATES_AS_TIMESTAMPS)
    .build();

When you search jackson-datatype-jsr310 maven and see versions that mirror jackson-databind's, that is by design: every Jackson component in a release wave shares the same version number. Sibling modules worth knowing: jackson-datatype-jdk8 (for Optional), jackson-module-parameter-names (constructor binding without explicit annotations), and the jackson-dataformat-* family (YAML, XML, CSV) under yet another group, com.fasterxml.jackson.dataformat. Spring Boot registers jsr310, jdk8, and parameter-names automatically when they are on the classpath.

Version alignment: use the BOM, not vigilance

Jackson's biggest operational hazard is version skew: jackson-databind 2.19 sitting next to a jackson-datatype-jsr310 2.15 that some other library dragged in. Symptoms range from NoSuchMethodError at runtime to subtle serialization differences. The cure is the official BOM:

<dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>com.fasterxml.jackson</groupId>
      <artifactId>jackson-bom</artifactId>
      <version>2.19.0</version>
      <type>pom</type>
      <scope>import</scope>
    </dependency>
  </dependencies>
</dependencyManagement>

With the BOM imported, you omit versions on every individual Jackson dependency and all of them, core trio, datatype modules, dataformats, resolve to one consistent wave. Verify with mvn dependency:tree -Dincludes=com.fasterxml.jackson* and treat any mixed versions in the output as a build bug.

Spring Boot users get this for free: the Boot parent manages Jackson versions, and the correct way to move is to upgrade Boot or override the jackson-bom.version property, never to hard-pin one artifact.

Version strategy: minors, micro-patches, and the 3.0 horizon

Jackson 2.x ships a new minor roughly twice a year (2.19.0 arrived in April 2025), and, importantly for security response, publishes micro-patches on old branches when a fix matters: versions like 2.12.6.1 and 2.13.2.1 exist specifically to deliver a security fix without forcing a minor upgrade. A sane policy:

1. Track the current minor within a quarter or two of release, via the BOM.
2. When a CVE lands, check whether your branch got a micro-patch; those four-segment versions are drop-in by design.
3. Watch the horizon: Jackson 3 is being developed under new coordinates (tools.jackson.*), with com.fasterxml.jackson.* remaining for the 2.x line, so a future migration will be an explicit coordinate change, not a surprise upgrade.

Why scanners care so much about this artifact

jackson-databind has one of the most storied CVE histories in the Java ecosystem, and understanding its shape makes triage rational instead of alarming. The bulk of it is the polymorphic deserialization era: with default typing enabled (or certain annotations), attacker-controlled JSON could name a "gadget" class to instantiate, and CVE-2017-7525 plus dozens of follow-on gadget-class CVEs chased that pattern through the 2.7–2.9 years. Jackson 2.10 (2019) restructured the feature around PolymorphicTypeValidator, replacing the blocklist arms race with explicit allowlists:

PolymorphicTypeValidator ptv = BasicPolymorphicTypeValidator.builder()
    .allowIfSubType("com.mycompany.model.")
    .build();
mapper.activateDefaultTyping(ptv, ObjectMapper.DefaultTyping.NON_FINAL);

If your code still calls the deprecated enableDefaultTyping(), that is a finding regardless of your version.

The modern era's issues are tamer: CVE-2020-36518, a stack-overflow denial of service from deeply nested JSON (fixed in 2.12.6.1 and 2.13.2.1), is representative, resource exhaustion rather than remote code execution. Because jackson-databind is present in effectively every JVM service, usually transitively through frameworks, it is a fixture in SCA scan results; a tool such as Safeguard will map which of your services carry a vulnerable range and whether the fix is a micro-patch or a minor bump. For the deserialization history in depth, see our Jackson security guide.

A checklist for your next pom review

• Declare com.fasterxml.jackson.core:jackson-databind, never a group named after the Java package.
• Import jackson-bom in dependencyManagement; drop per-artifact versions.
• Add jackson-datatype-jsr310 if any java.time type crosses your JSON boundary, and register JavaTimeModule (or let Spring Boot do it).
• Grep for enableDefaultTyping and replace with validator-based activation, or better, model polymorphism explicitly with @JsonTypeInfo and named subtypes.
• Confirm mvn dependency:tree shows one Jackson version, and let your scanner verify the range is current.

FAQ

What is the Maven dependency for com.fasterxml.jackson.databind?

Group ID com.fasterxml.jackson.core, artifact ID jackson-databind. The string com.fasterxml.jackson.databind is the Java package inside that artifact, not a valid group ID, nothing is published under it.

Do I need jackson-core and jackson-annotations separately?

No. Declaring jackson-databind pulls both in transitively at the matching version. Declare them explicitly only if you need to manage their versions directly, and prefer the jackson-bom for that.

What is jackson-datatype-jsr310 for?

It supplies JavaTimeModule, which teaches Jackson to handle java.time types (LocalDate, Instant, ZonedDateTime) as ISO-8601 strings. Its Maven group is com.fasterxml.jackson.datatype, and its version should always match your jackson-databind version.

Is jackson-databind safe to use given its CVE history?

Yes, on current versions with sane configuration. The severe remote-code-execution era targeted default typing, redesigned in 2.10 around allowlist validators; recent CVEs like CVE-2020-36518 are denial-of-service class. Keep to a supported minor, apply micro-patches promptly, and never enable default typing without a PolymorphicTypeValidator.