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: >>> >>> 1. *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. >>> 2. *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. >> >>> >>> 1. *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 >> >> >>> 1. *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. >> >>> >>> 1. *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). >> >
