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 >
