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?