Upgrade Java SDK to Jackson 3 alongside Java 17 baseline upgrade

[viswapriya22]

When upgrading the Dapr Java SDK baseline from Java 11 to Java 17 in 1.18 (#1694), please also upgrade the core SDK from Jackson 2 (com.fasterxml.jackson) to Jackson 3 (tools.jackson).

PR #1657 added Jackson 3 support for the Spring Boot 4 autoconfigure module, but the core SDK still ships with Jackson 2. For users on Spring Boot 3.5+ / Java 17+ this means we still inherit Jackson 2 transitively and must manually exclude it making it fragile.

A native upgrade to Jackson 3 in the core SDK would eliminate this issue for all users on Java 17+.

[salaboy]

@viswapriya22 thanks for reporting this issue, but can you explain me a bit more your setup? Are you using Spring Boot 3.x or Spring Boot 4?
Are you using Spring Boot 3.5 with Jackson 3?
The current approach was to support Spring Boot 4.x with Jackson 3 and keep Spring Boot 3.x with Jackson 2 by default.

What issue are you experiencing right now? I think that manually excluding Jackson2 if you are using Spring Boot 3.x would be ok in my opinion. What benefits do we get by supporting Jackson3 in the Core SDK?

[viswapriya22]

@salaboy thanks for the quick response.

We’re currently on Spring Boot 3.5 / Jackson 2, but planning to move to Spring Boot 4/ Jackson 3 soon.

Even if we use dapr-spring-boot-4-starter, our app will still pull Jackson 2 transitively because the core SDK depends on Jackson 2
https://github.com/dapr/java-sdk/blob/master/pom.xml#L125

So a SB4 app ends up with both Jackson 3 and Jackson 2 on the classpath unless we maintain exclusions, which is brittle.

Upgrading the core SDK to Jackson 3 would give SB4 users a clean dependency graph and avoid carrying two Json stacks. This would also align with the SB4 lane introduced in #1657 and the Java 17 baseline work in #1694. Let me know if I’m missing anything.

[salaboy]

@viswapriya22 ok but if we do that, then SB 3.x users will get Jackson 3 , right?

[Sarthak-Biswas]

@viswapriya22 ok but if we do that, then SB 3.x users will get Jackson 3 , right?

Better approach would be to have a new class called Jackson3ObjectSerializer just like how it is done in this PR: f58ba03, also providing a way to configure the ObjectMapper/JsonMapper since the mapper is immutable in jackson 3.

And users should be able to chose which serializer they want to use, the default jackson 2 one or the jackson 3 one.

[salaboy]

@Sarthak-Biswas thanks for jumping in, so that PR was merged already -> https://github.com/dapr/java-sdk/blob/master/dapr-spring/dapr-spring-boot-4-autoconfigure/src/main/java/io/dapr/spring/boot4/autoconfigure/client/Jackson3ObjectSerializer.java and we have a Jackson3ObjectSerializer. From your comment I am not sure what you are trying to suggest. I think we are already supporting what you suggested. If not, can you please elaborate on your proposal?

[wbeiter]

My two cents - typically I would expect to see a major version bump in the core-sdk according to the breaking change that is introduced by the ABI change by virtue of Jackson's package restructuring. That could result in a need to maintain two major versions of the core sdk (and downstream modules) for some period of time, and associated deprecation of the current v1 (which uses Jackson 2, which won't be maintained forever either). Is that too invasive?

[javier-aliaga]

Thanks @viswapriya22 for raising this and everyone for the discussion.

As @salaboy pointed out Spring Boot 4 users already get Jackson 3 automatically. The dapr-spring-boot-4-autoconfigure module ships a Jackson3ObjectSerializer that kicks in when Jackson 3 is on the classpath via @ConditionalOnClass(JsonMapper.class), so SB4 apps get native Jackson 3 serialization without any manual configuration.

We cannot move Jackson 3 into the core SDK as it would mean SB 3.x users get Jackson 3 transitively, which is not what we want.

We haven't decided yet when SB 3.x support will be deprecated (#1718), so we need to keep the core SDK working for both user bases.

We also recently introduced the dapr-sdk-bom (#1722) and dapr-spring-bom so consumers can pin all artifact versions and get security-patched transitive dependencies without manual exclusions.

Once SB 3.x is deprecated we will migrate the core SDK to Jackson 3.