We seem to be in agreement here on using Java 17 features. We already switched to Java 17 via https://github.com/apache/iceberg/pull/14400.
I noticed iceberg-core currently has 257 warnings related to Java 17 features. All the warnings are related to switch statements and casts after instanceof checks. Here is a PR to fix those: https://github.com/apache/iceberg/pull/15494 Cheers, Max On Wed, Jan 14, 2026 at 12:22 PM Eduard Tudenhöfner <[email protected]> wrote: > > I'm generally in favor of adopting JDK 17 features > > On Wed, Jan 14, 2026 at 11:23 AM Péter Váry <[email protected]> > wrote: >> >> From my experience, records work well for internal structures. However, >> since they are effectively immutable and difficult to evolve, they are not >> ideal as input or output parameters for API methods. >> >> Steve Loughran <[email protected]> ezt írta (időpont: 2026. jan. 13., K, >> 22:54): >>> >>> >>> >>> On Tue, 13 Jan 2026 at 17:39, Péter Váry <[email protected]> >>> wrote: >>>> >>>> Since we are moving to Java 17 and dropping Java 11 support, we can start >>>> taking advantage of the language features introduced in Java 17. >>>> >>>> Some notable examples include: >>>> >>>> Pattern Matching for instanceof – Simplifies type checks by allowing >>>> variable binding directly in the condition (e.g., if (obj instanceof >>>> String s)), removing the need for manual casting. >>>> Switch Expressions – Extend switch with an expression form that returns a >>>> value, uses the arrow (->) syntax, prevents fall‑through by default, and >>>> eliminates the need for break statements. >>> >>> powerful, saves on code and reduce risk of errors through accidental fall >>> through. >>>> >>>> Text Blocks – Multi-line string literals using triple quotes ("""), making >>>> embedded JSON, SQL, and similar content far easier to read and maintain. >>> >>> >>> these are wonderful, especially for writing tests, though the indentation >>> rules are a bit subtle >>> https://docs.oracle.com/en/java/javase/17/text-blocks/index.html >>> >>>> Records – A restricted class type designed to represent immutable data >>>> carriers. Records automatically generate constructors, accessors, and >>>> implementations of equals(), hashCode(), and toString(), substantially >>>> reducing boilerplate for DTO‑style objects. >>> >>> good for simple abstract data types; no experience in bigger roles. >>>> >>>> Sealed Classes and Interfaces – These allow us to explicitly control which >>>> classes or interfaces may extend or implement a given type, enabling >>>> clearer and more maintainable inheritance hierarchies. >>> >>> These are probably the most conceptually complex and hardest to get right. >>> And I don't know what happens across versions (sealing something which >>> wasn't before, changing subclass attributes). Best to assume it is like >>> adding final or abstract to a class: you can break all subclasses. >>> >>>> >>>> I think we should begin using some of these features—specifically pattern >>>> matching, switch expressions, and text blocks—in new code whenever >>>> appropriate. >>>> I’m less convinced about adopting records due to their limitations around >>>> inheritance and extensibility, and I don’t currently have a strong opinion >>>> on sealed classes. >>>> >>>> Does anyone have concerns about adopting any of these features? >>>> >>>> >>> >>> No, except for any large scale use of sealed. It'll take time to get right, >>> and while the examples all assume you are putting the classes into the same >>> module, in open source you don't get that ability to control what sneaks >>> into your packages and modules -sometimes because they have to (example, >>> spark almost mandating it [spark] packaging for complex use).
