Hi Robert, Your approach looks good to me. If we can avoid the giant Quarkus-4 PR and introduce the changes gradually, that's a very valuable option.
I would like though to have a better understanding of the situation regarding Iceberg REST serializers, which are still Jackson 2: - Should we engage with the Iceberg community and start a migration discussion there as well? - How would the HTTP layer in Quarkus 4 serialize an Iceberg type, e.g. ConfigResponse? Would it use Iceberg's ConfigResponseSerializer, or something else? Thanks, Alex On Wed, Jun 24, 2026 at 4:42 PM Robert Stupp <[email protected]> wrote: > > 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
