Hi all, As more frameworks (like Spring Boot and Quarkus) migrate to Jackson 3, I wanted to open a conversation about what a Jackson 3 migration would look like for Iceberg and what trade-offs we should think through together.
Iceberg currently depends on Jackson 2 in several modules, most significantly iceberg-core. Other modules with direct Jackson dependencies include iceberg-aws, iceberg-nessie, iceberg-snowflake, and iceberg-kafka-connect. Most modules could be migrated separately. The migration is largely mechanical but pervasive: artifact coordinates and Java package names change across the board, several core classes and methods are renamed, ObjectMapper construction moves to a builder pattern, and exceptions become unchecked. JDK 17 is required, which Iceberg already enforces. The blast radius for iceberg-core would be roughly: - Spark and Flink runtime JARs: low impact. Both already shade Jackson 2; adding a relocation rule for Jackson 3 is a one-line fix per runtime variant. - Kafka Connect: also low impact, although the Kafka Connect distribution uses unshaded JARs. - Downstream users of iceberg-core: this is the most significant concern. Jackson types leak into the public API of many XYZParser classes, JsonUtil, and the REST HTTP layer. The honest answer is that icebegr-core's public API is permanently Jackson-coupled by design. We should imho acknowledge this fact; the best migration approach is to add Jackson 3 overloads wherever applicable, and make Jackson 2 and 3 coexist for some time. Looking forward to hearing your thoughts on this topic. Thanks, Alex
