What about moving to JSON-B? 🤔 I know it can look like it misses fun feature but there is no technical reason you don't manage to do all you want with it. Will be more consistent with microprofile and more future friendly IMHO for the project.
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 ven. 13 févr. 2026 à 16:03, Alexandre Dutra <[email protected]> a écrit : > Hi Robert, > > Good point about Jackson 3, I agree that we should migrate ahead of > Quarkus if possible, and that a code-first approach would make things > easier. > > That said, it seems that support for Jackson 3 is now deferred to Quarkus > 4 [1]. > > Thanks, > Alex > > [1]: https://github.com/quarkusio/quarkus/issues/52036 > > On Fri, Feb 13, 2026 at 3:18 PM Robert Stupp <[email protected]> wrote: > > > > Another aspect, although strictly speaking unrelated, is Jackson 3. All > > custom Jackson 2 serializers are incompatible with Jackson 3, and some > > annotations are different. It is possible to use both Jackson 2 + 3 > > annotations in the "code first" approach, and it works fine with > Immutables. > > > > I'd expect Jackson 3 to become a necessity in the near future. For > Quarkus, > > it was already on the list of ideas for 3.31, but thankfully moved out. > > A "code first" approach would save us that headache in the JAX-RS > context. > > > > Side note: it's possible to use both Jackson 2 and Jackson 3 in the same > > code base - they can work side by side. > > > > > > On Fri, Feb 13, 2026 at 3:00 PM Jean-Baptiste Onofré <[email protected]> > > wrote: > > > > > Hi Dmitri, > > > > > > Thanks for starting this discussion. > > > > > > While I have a preference for the code-first approach, I wonder if we > can > > > easily support the Iceberg REST Spec using this method. I would like > to use > > > JaxRS annotations, but it might be tricky to cleanly leverage the > Iceberg > > > REST Spec. > > > > > > Just my $0.01 > > > > > > Regards, > > > JB > > > > > > On Thu, Feb 12, 2026 at 5:04 PM Dmitri Bourlatchkov <[email protected]> > > > wrote: > > > > > > > Hi All, > > > > > > > > I believe OpenAPI (REST) interface definitions that Polaris provides > are > > > > very useful for end users and machine clients. > > > > > > > > However, I see that server-side code generation leads to duplication > > > > between generated code and hand-written code. For example, > > > > `PolarisCatalogsApi` is generated, but most of the method signatures > in > > > > `PolarisServiceImpl` have to be written by hand to match the > generated > > > > code. > > > > > > > > I wonder what people think about using direct hand-written service > > > classes > > > > to connect to REST endpoints via Rs-Api (Jakarta) annotations? > > > > > > > > I can see that generating service stubs might appear helpful to > ensure > > > that > > > > all API endpoints have code that matches OpenAPI specs. However, we > have > > > to > > > > make tests to verify correct behaviour anyway. Those tests could be > made > > > > with a generated client and will automatically ensure correct > > > hand-written > > > > code assuming coverage is good. > > > > > > > > WDYT? > > > > > > > > Thanks, > > > > Dmitri. > > > > > > > >
