Java Records: Immutable Data Carriers

Records are immutable data carriers — all fields are final, the class itself is final, and the compiler auto-generates a canonical constructor, accessors, equals(), hashCode(), and toString() based on all components.

What the compiler generates:

• private final fields for each component
• Accessor methods named x() and y() — not getX(), breaking JavaBean convention
• equals()/hashCode() covering all fields — safe as HashMap keys out of the box

Compact constructors:

• Validate without boilerplate: record Email(String value) { Email { if (!value.contains("@")) throw ...; value = value.toLowerCase(); } }
• Modify the parameter, not the field — this.value = value happens automatically after the body

Limitations and gotchas:

• Cannot extend classes (implicitly extends java.lang.Record) or be subclassed
• Mutable components (like List) are not defensively copied — use List.copyOf(items) in the compact constructor
• Accessors use x() not getX() — some JSON serializers and older frameworks need configuration

I recommend records for DTOs, composite return types, and map keys — for JPA entities or anything needing mutable state, use regular classes.