Hi everyone, I would like to start a discussion about Jackson 3 readiness for Polaris.
This is not about upgrading Polaris to Quarkus 4 right now. Polaris is still on Quarkus 3, and I do not think we should turn this into a big platform-upgrade thread. But Quarkus 4 is expected to move to Jackson 3. The current public roadmap mentions Jackson 3 as part of Quarkus 4, with Beta 1 tentatively around September 2026 and GA around November 2026. I think that matters for Polaris because Jackson is not only used in isolated helper code. Quarkus also owns important runtime paths for us, including REST request/response mapping. Once we move to Quarkus 4, Jackson 3 is expected to be on that path. We already have a smaller example showing why this is not just a theoretical dependency cleanup. In the Quarkus 3.37 work, Polaris currently has to keep the Quarkus REST Jackson reflection-free serializer optimization disabled. With that optimization enabled, the generated REST JSON path does not behave the same as the customized ObjectMapper path for some Iceberg REST request types. One concrete symptom was namespace creation deserializing incorrectly. That is not a Jackson 3 bug by itself. But it is a good reminder that the exact Quarkus/Jackson REST integration path matters for Polaris correctness. I have started splitting out a few smaller Jackson 3 preparation PRs already. The idea is to reduce the local migration surface where we can do that safely: - migrate small Polaris-internal serializers/deserializers first; - keep the JSON wire format stable and covered by tests; - avoid mixing behavior changes into the migration; - leave dependency-constrained areas on Jackson 2 until the dependency path is clear. I think this is lower risk than waiting until a future Quarkus 4 upgrade PR has to solve everything at once. There are still areas where Polaris depends on libraries that expose or use Jackson 2 JSON mapping APIs. Iceberg is one important example, because Polaris relies on Iceberg types and REST-related model handling. I do not think the Polaris dev list is the place to decide Iceberg's dependency policy. But I do think Polaris should track this as a Quarkus 4 readiness constraint, so we know which parts are Polaris-owned and which parts are blocked on dependency APIs. My proposed direction is: 1. Treat Jackson 3 readiness as encouraged for new Polaris-internal JSON code. 2. Accept focused PRs that migrate isolated Polaris code paths to Jackson 3 when tests show the JSON contract stays stable. 3. Avoid introducing new Jackson 2 usage unless a dependency API requires it. 4. Track remaining Jackson 2 usage by category: Polaris-owned, dependency-constrained, test-only, and distribution/license-only. 5. Use that tracking to identify what must be resolved before a Quarkus 4 upgrade becomes practical. This does not need to be a vote. I am mostly looking for agreement on the direction and on how we want to track the remaining blockers. Does this sound like the right approach? Robert
