Migrate JSON bindings to Jackson 3#678
Conversation
Rename module and package to jackson3, move to tools.jackson 3.2.0, translate unchecked JacksonException to IOException, target Java 17.
| echo 'HC_BUILD_TOOLCHAIN_VERSION=${{ matrix.java }}' >> "$GITHUB_ENV" | ||
| ;; | ||
| esac | ||
| # The httpcore5-jackson3 module is compiled for Java 17 (Jackson 3 |
There was a problem hiding this comment.
@arturobernalg Looks good to me.
Just for my understanding. Why do not we do something similar for the jakarta-rest-client module in client? It also requires Java 11. How does it work there?
There was a problem hiding this comment.
In the client, jakarta-rest-client targets Java 11, so it only breaks on the Java 8 row — it stays in the reactor and a skip-on-java8 profile no-ops its build there. jackson3 targets Java 17, so it has to be dropped on both the Java 8 and Java 11 rows, which a single-value skip profile can't express cleanly — hence the reactor exclusion via the jackson3 profile. Happy to switch core to the same keep-in-reactor + skip pattern if you'd prefer them consistent.
There was a problem hiding this comment.
@arturobernalg Got it. I would prefer it to be consistent across all our projects especially given that jakarta-rest-client will require Java 17 as well once upgraded to httpcore5-jackson3. The exact approach is up to you to choose.
There was a problem hiding this comment.
@ok2c
Agreed. I'll leave jackson3 as-is and align the client's jakarta-rest-client to the same -Dhc..skip reactor-exclusion so both projects match (and it cleanly covers the future Java 17 bump).
2 participants
Rename module and package to jackson3, move to tools.jackson 3.2.0, translate unchecked JacksonException to IOException, target Java 17.