Hi Alex, Romain, Thanks, both.
Alex, yes, I think we should eventually have the corresponding discussion on the Iceberg side as well. I would just prefer to first make the Polaris impact clear here: which Jackson usage is Polaris-owned, which usage is only test/distribution surface, and which usage is constrained by dependency APIs. On the Quarkus HTTP path: today Polaris registers Iceberg's REST serializers via the Quarkus ObjectMapper customizer: RESTSerializers.registerAll(objectMapper) For the normal Quarkus REST Jackson path, I would expect Iceberg types such as ConfigResponse to go through that customized ObjectMapper path. The issue is that this is also the fragile part. With Quarkus REST's reflection-free serializer/deserializer optimization, Quarkus can use generated handling for request/response body types. We already saw that this is not equivalent for some Iceberg REST request types: create-namespace was one concrete case where the request body was not deserialized correctly. So I think there are two different milestones here: 1. Iceberg JSON support can run on Jackson 3. 2. Iceberg REST model types are self-describing enough that Quarkus generated REST serializers/deserializers can handle them correctly without relying on externally registered ObjectMapper modules for the core wire format. Those are related, but not the same. Romain, I agree that JSON-B/JSON-P is an interesting API-boundary direction in general. But I do not think it is the practical near-term answer for this issue. JSON-B helps when the runtime uses a JSON-B provider. JSON-P is lower-level JSON processing. Neither directly helps existing Iceberg code paths that use Jackson ObjectMapper/JsonMapper, nor consumers that rely on Iceberg's Jackson-based REST parsers and serializers. For this specific problem, I think the cleaner long-term shape is that the Iceberg REST model types become Jackson-self-describing: mostly regular Jackson annotations for properties/builders/naming, and only custom serializers where the wire format actually cannot be represented otherwise. That should also be compatible with a transition period. Many core Jackson annotations are still in `com.fasterxml.jackson.annotation` and work across Jackson 2/3. Where databind-specific annotations differ, the Jackson 2 and Jackson 3 annotations can be duplicated on the model types if needed. Polaris could work around this with local wrapper DTOs/adapters. Nessie has a model like that and it works with Quarkus 3.37 and reflection-free serializers. The difference is that Nessie owns that path end-to-end and can handle those types directly. Polaris is much more tied to Iceberg's REST model types and services, so introducing a local shadow model here would be a bigger local ownership decision. The drift argument is still real: if Polaris re-implements Iceberg REST payload types locally, we have to keep that model aligned with Iceberg's REST API over time. That may be doable, but I would rather not make it the default answer if the Iceberg REST model types can become self-describing instead. So my current view is: - short term: keep migrating Polaris-owned JSON usage where it is isolated and testable - short term: track Iceberg REST model handling as dependency-constrained - longer term: discuss in Iceberg whether the REST model types can move toward a self-describing Jackson annotation model, so consumers do not need externally registered manual serializers for basic REST request/response correctness. That would make a future Quarkus 4/Jackson 3 upgrade much less risky for Polaris. Robert On Wed, Jun 24, 2026 at 11:06 PM Romain Manni-Bucau <[email protected]> wrote: > Hi guys, > > maybe encouraging JSON-P+JSON-B as API then any vendor/impl can pick its > preferred vendor can be a neat choice for the future instead of relying > deeply on jackson? > quarkus already supports it and work in iceberg is not crazy - not speaking > of the community discussion not spark and friends integrations ;) > > Romain Manni-Bucau > @rmannibucau <https://x.com/rmannibucau> | .NET Blog > <https://dotnetbirdie.github.io/> | Blog <https://rmannibucau.github.io/> > | Old > Blog <http://rmannibucau.wordpress.com> | Github > <https://github.com/rmannibucau> | LinkedIn > <https://www.linkedin.com/in/rmannibucau> | Book > < > https://www.packtpub.com/en-us/product/java-ee-8-high-performance-9781788473064 > > > Javaccino founder (Java/.NET service - contact via linkedin) > > > Le mer. 24 juin 2026 à 18:03, Alexandre Dutra <[email protected]> a écrit > : > > > 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 > > >
