(from the phone) Neat thing with jsonb as an api is you can décorateur it - even with CDI and abstract decorator or interceptors - and migrate class by class, some backed by jackson, other by whatever works
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 jeu. 25 juin 2026, 09:42, Robert Stupp <[email protected]> a écrit : > 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 > > > > > >
