Thanks Yufei. I agree that keeping
quarkus.rest.jackson.optimization.enable-reflection-free-serializers=false is a reasonable workaround for the Quarkus 3.37 upgrade. I do not think we should treat that as the Quarkus 4 / Jackson 3 readiness answer, though. That flag disables one generated Quarkus REST JSON path in the current Quarkus 3.x line. It does not make Iceberg's Jackson 2 serializers, parser APIs, or ObjectMapper integration usable with a Jackson 3 runtime path. That is the distinction I wanted to make with the reflection-free serializer example. It is not the same issue as Jackson 3, nor is it proof of a Jackson 3 bug. It is evidence that Polaris' REST correctness depends on the exact Quarkus/Jackson integration path and on preserving Iceberg's registered ObjectMapper module behavior. So I think there are still two separate tracks: 1. For Polaris-owned JSON usage, keep migrating isolated code paths to Jackson 3 when the wire contract is covered by tests. 2. For Iceberg REST model handling, track it as dependency-constrained for Polaris' eventual Quarkus 4 readiness. I agree that the Iceberg-side migration timeline is an Iceberg project decision. >From the Polaris side, I do not think we should leave that as an implicit unknown. We should record it as a readiness blocker/category, even if the action is only "needs upstream discussion" for now. For the reflection-free serializers specifically, I would not frame the desired future as "Polaris must use this optimization." The more important point is that ordinary REST model mapping should not depend on every downstream framework preserving one exact manually registered ObjectMapper path. Where Iceberg needs custom parser logic for versioning, compatibility, polymorphism, or parser context, that should stay explicit. But where REST request/response models are ordinary property mappings, making those models more self-describing would make framework-managed HTTP runtimes less fragile. Robert On Fri, Jun 26, 2026 at 2:38 AM Yufei Gu <[email protected]> wrote: > 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 > > > > > > > > > > > > > > > > > > > > >
