>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). >
