[Feature]: Support for Jackson3

[kalmes-adesso]

Feature summary

Add support for Jackson3

Problem statement

We're currently using the Adyen library in a service that uses SpringBoot 3. We would like to update our service to SpringBoot4. That change includes going from Jackson2 to Jackson3.

As of now the Adyen library does not support Jackson3.

Proposed solution

Create a new artifact that uses Jackson3 instead of Jackson2. This would support both options.

Alternatives considered

We considered running Jackson2 and Jackson3 at the same time. That is not a valid solution for us.

Additional context

No response

[jeandersonbc]

Hi @kalmes-adesso, thanks for reaching out. We need to assess the feasibility of doing this migration first. I see that Jackson 3 requires JDK 17, while we still have to support Java 11.

Was there something in particular that didn't work when attempting Jackson2 compatibility (as described here: https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-4.0-Migration-Guide#jackson-2-compatibility)?

[kalmes-adesso]

Hi @jeandersonbc, we're directly using some of the classes from the adyen lib on our endpoints as dto/part of dtos. When we switch to jackson3 the provided Deserializers from the adyen lib will fail since they depend on jackson classes that have changed package in jackson3.

Running both jackson2 and jackson3 in parallel does also not work here since the endpoints are already used on production.

[jaredtbates]

We're hitting the same thing, and are choosing to stay on Jackson 2 due to Adyen's SDK for the time being. Hoping this will at least be planned at some point!

[thomasc-adyen]

@jaredtbates @kalmes-adesso thanks for sharing your use cases. We will discuss with the team and come back to you on whether this is something we can prioritize on our roadmap for the Java library.

[gregjotau]

A second Jackson 3 artifact is the wrong shape. Please ship a major that drops Java 11, baselines on Java 17 (21 is better), and switches the library to Jackson 3.

Java 11 is the only real blocker named here, and it is holding the library back for no good reason:

• Jackson 3 requires JDK 17. That is not optional.
• Spring Boot 4 already moved the ecosystem to Jackson 3. Anyone on Boot 4 is already on 17+.
• You already ship breaking majors (v43 just broke Checkout v71 → v72). A Java/Jackson major is the same kind of change, and it is easier to consume than another Checkout field rename.
• Dual-artifact (adyen-java-api-library + -jackson3) doubles generated models, templates, CI, and release surface forever. You will regret that the first time a oneOf deserializer needs a fix in both trees.
• Running Jackson 2 and 3 side by side is fine as a consumer workaround. It is not a library strategy. The generated StdDeserializer / StdSerializer classes (CheckoutPaymentMethod, transfer account IDs, etc.) bind to com.fasterxml.jackson.databind. Those types moved. Consumers that put Adyen models on Boot 4 endpoints cannot use this library correctly until this artifact is on Jackson 3.

Keeping Java 11 does not protect users. It freezes the SDK on an old JSON stack while every serious Java app that still cares about this library is already past 11. Upgrading 11 → 17/21 is mechanical now. What is not mechanical is maintaining two serialization backends and a Java 11 floor for years.

Concrete proposal:

1. Next major (44 or whatever you call it): maven.compiler.release 17 at minimum, 21 if you are willing to jump once.
2. Replace com.fasterxml.jackson.core:jackson-databind 2.x with tools.jackson.core:jackson-databind 3.x. Annotations stay on com.fasterxml.jackson.annotation.
3. Port templates-v7 (or upgrade OpenAPI Generator — current jersey3 already has useJackson3=true) and regenerate. Do not hand-edit ~1900 models.
4. Rewrite the handful of handwritten databind types (ByteArraySerializer / ByteArrayDeserializer, SaleToAcquirerDataParser, JSON.getMapper() → JsonMapper).
5. One artifact. No Jackson 2 transitive. No parallel Jackson 3 module.

We run this library on Spring Boot 4 / Jackson 3 today and already carry Jackson 2 only because of Adyen. Happy to send the template + handwritten PR once you confirm the major will drop 11.

Please do not park this as “maybe a second artifact later.” Cut the major.

[gregjotau]

We implemented the Java 17/Jackson 3 proposal for testing:

• library PR: Migrate to Java 17 and Jackson 3 #2047
• generator companion PR: Preserve Jackson 3 imports in generated Java SDKs adyen-sdk-automation#154
• Beint source release: https://github.com/beint-no/adyen-java-api-library/releases/tag/v44.0.0-beint.2
• Maven Central: https://central.sonatype.com/artifact/no.beint.adyen/adyen-java-api-library/44.0.0-beint.2

Anyone who wants to try the Beint fork can use:

<dependency>
  <groupId>no.beint.adyen</groupId>
  <artifactId>adyen-java-api-library</artifactId>
  <version>44.0.0-beint.2</version>
</dependency>

The release requires JDK 17+ and uses Jackson 3 core/databind. Jackson annotations intentionally remain on the 2.x artifact/package because Jackson 3 continues to share that annotations component.

This is an unofficial Beint test release and is not supported or endorsed by Adyen. Version 44.0.0-beint.2 supersedes the initial .1 test build with a mapper visibility fix identified during PR review.

[gregjotau]

Thanks for raising the Java 11 compatibility concern earlier. I understand that dropping a supported runtime is a real product decision, not just a build change.

I have reshaped the two PRs to make that decision easier to review:

• the library PR now has focused Jackson 3 regression tests for mapper rebuilding/config preservation, concurrent mapper visibility, oneOf deserialization, and byte-array round trips
• the automation PR no longer upgrades OpenAPI Generator; it stays on 7.11.0 and adds one explicit Jackson 3 import mapping, avoiding unrelated generated-code churn
• service-specific regeneration is clean, the full generator run succeeds, and the PR descriptions now explain the unrelated API snapshot drift in the full-services output
• the 622-test library build and a downstream Spring Boot 4 application build pass

@jeandersonbc @thomasc-adyen, if the team would prefer this split differently—for example, sequencing the template/import-mapping change first or targeting a particular next-major window—I am happy to adapt the PRs. Could you also approve the external-contributor workflow runs when convenient and let me know which PR you would like reviewed first?

• library workflow: https://github.com/Adyen/adyen-java-api-library/actions/runs/32625455190
• automation workflow: https://github.com/Adyen/adyen-sdk-automation/actions/runs/32625461029

[gregjotau]

An update from our side following #2047 and Adyen/adyen-sdk-automation#154: we have now merged the complete removal of the Adyen Java SDK from ReAI, including our Jackson 3 fork. We have archived the SDK and generator forks and are no longer maintaining those releases.

Jackson 3 compatibility prompted the fork, but reviewing the dependency footprint made the broader trade-off clear. We do not want to maintain a vendor SDK fork or carry unrelated API families and serialization dependencies just to keep our application on a current Java/Jackson stack.

Our replacement is an application-owned Adyen module using our existing Spring HTTP client and Jackson 3, with immutable Kotlin DTOs checked against Adyen's published OpenAPI definitions. It covers the 33 operations we use and 93 wire DTOs, plus the relevant webhook handling.

Concrete numbers from our resolved runtime dependency graph:

• Our published 44.0.0-beint.2 SDK JAR was 8.28 MiB and 3,696 compiled classes.
• Removing it also eliminated Gson, Error Prone annotations, and the Jakarta REST API from our runtime dependencies.
• Those four JARs totaled 8.74 MiB, before accounting for the replacement code. This measures dependency JAR bytes; we have not measured heap or startup improvements. Dependencies still required elsewhere in our application are excluded from that saving.

The SDK does provide useful behavior: endpoint selection, authentication, typed contracts, idempotency support, error handling, and webhook signature verification. We retained those responsibilities and checked contracts, transport behavior, and HMAC compatibility. Maintaining that narrower integration also means we own future API changes. The migration is merged; production verification is a separate follow-up.

What would make the official SDK compelling for us again:

1. A current Java/Jackson baseline with a clear upgrade and support policy. Supporting older applications should leave a path for the current major to adopt the modern ecosystem without consumers maintaining forks.
2. Separately consumable API-family modules, sharing a small core and optional webhook helpers, so consumers can include only the integrations they use.
3. Optional transport and serialization integrations, with legacy Terminal/Nexo dependencies isolated and documentation-only annotations optional, as discussed in Make Swagger annotation dependencies optional #2028.

The published OpenAPI definitions are valuable and made this approach practical. For our usage, owning a narrow HTTP integration is now a better trade-off than maintaining the fork. Timely ecosystem compatibility and modular packaging would materially change that calculation.