Robert, two tracks make sense to me. I'd also suggest documenting that the user cannot enable reflection-free-serializers, or provide a production ready check if possible. quarkus.rest.jackson.optimization.enable-reflection-free-serializers=false
Yufei On Fri, Jun 26, 2026 at 12:30 AM Robert Stupp <[email protected]> wrote: > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > >
