Hi I think it’s two related efforts: - first Jackson 3. Robert’s proposal looks good to me, especially avoiding Quarkus 4 major upgrade. - json-b is interesting indeed, especially using Johnson. For instance Karaf-decanter can support both Jackson and Johnson thanks to json-b. However I think it’s another discussion.
I would suggest to start with jackson3 upgrade now and investigate json-b api use as a follow up. Regards JB Le jeu. 25 juin 2026 à 10:01, Romain Manni-Bucau <[email protected]> a écrit : > (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 > > > > > > > > > >
