While I’m not particular about the tools, I’m pretty strongly in favor of the spec first approach. While the management APIs have the freedom to be code-first, the Iceberg catalog APIs are subject to a spec outside of our control. Adding in tools later to ensure compatibility feels unnecessarily complex and just adds another thing we have to know about and maintain. I’d be in favor of evaluating simpler, less verbose generators.
Mike On Fri, Feb 13, 2026 at 2:25 PM Romain Manni-Bucau <[email protected]> wrote: > 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. > > > > > > > > > > > >
