Hi Robert, Thanks for raising this thread. I shared Alex's concern about how Jackson 3 will work with Iceberg REST serializers that are still based on Jackson 2.
I believe the reflection-free serializers are a separate issue since they already exist in the current Quarkus release. We can simply keep that optimization disabled: quarkus.rest.jackson.optimization.enable-reflection-free-serializers=false Let me know if I missed anything. Waiting for Iceberg to migrate to Jackson 3 before moving Polaris to Quarkus 4 makes sense to me. We should thoroughly test the HTTP request and response paths once everything is in place, but that seems like a way to move forward. The Iceberg Jackson 3 migration timeline is unknown to me, we could get started now or we could just wait. Yufei On Thu, Jun 25, 2026 at 1:30 AM Jean-Baptiste Onofré <[email protected]> wrote: > 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 > > > > > > > > > > > > > > >
