Do we still need Guava Immutables now that we have records? On Tue, Jan 13, 2026 at 12:14 PM Anton Okolnychyi <[email protected]> wrote:
> I am using most of these for the upcoming Spark 4.1 integration and I find > them useful. I think we should embrace these concepts throughout the code > for new development. > > - Anton > > вт, 13 січ. 2026 р. о 09:40 Péter Váry <[email protected]> пише: > >> 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. >> 3. *Text Blocks* – Multi-line string literals using triple quotes >> ("""), making embedded JSON, SQL, and similar content far easier to read >> and maintain. >> 4. *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. >> 5. *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. >> >> 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? >> >> Thanks, >> Peter >> >
