Record Fundamentals

A record is a special kind of final class, introduced as a standard feature in Java 16, that acts as a transparent carrier for a fixed set of values called components. From a header such as record Money(BigDecimal amount, Currency currency), the compiler generates a private final field and a public accessor for each component, a canonical constructor, and equals, hashCode and toString based on all components. Every record extends java.lang.Record and cannot extend anything else. The defining idea is that its API is exactly its state: there is no hidden state, so a record is shallowly immutable and can be rebuilt completely from its accessors.

Accessors use the component name itself, with no get or is prefix: point.x(), money.amount(), flag.enabled(). That is a deliberate break from the JavaBeans convention, because a record is not a bean, and it trips up older tools. Expression languages, some templating engines and hand-written reflection that look for getAmount() may not find the value, although current versions of Jackson, Spring, Hibernate Validator and MapStruct all recognise record accessors. You may declare an accessor explicitly, for example to return a defensive copy of an array, but it must be public, return exactly the component type and declare no checked exceptions, or the record will not compile.

Both are the canonical constructor, the one whose parameters match the components in order, and every record has exactly one. The explicit canonical form lists the parameters and must assign every field itself with this.amount = amount. The compact form omits the parameter list: the parameters are implicit, the body runs first, and the compiler then assigns each parameter to its field automatically. Inside a compact constructor you validate, normalise by reassigning the parameter, or make defensive copies, but you may not assign the fields directly; this.amount = x is a compile error. The compact form is preferred because it focuses on invariants and cannot forget a field assignment.

No to both. A record implicitly extends java.lang.Record, and Java has single inheritance, so it cannot extend another class; it is also implicitly final, so nothing can extend it. It may not declare instance fields beyond its components, nor instance initialiser blocks, because any hidden state would break the guarantee that a record is fully described by its header. What it can do is implement interfaces, often a sealed interface, and declare static fields, static methods, nested types, extra constructors and instance methods. Derived values such as a total or a full name should be computed in a method rather than cached in a field.

Put the logic in the compact canonical constructor, because every instance, whether created by your code, Jackson, a mapper or deserialization, must pass through it. Validate with Objects.requireNonNull and explicit checks that throw IllegalArgumentException with a clear message. Normalise by reassigning the implicit parameter, for example name = name.strip() or amount = amount.setScale(2, RoundingMode.HALF_EVEN). Make defensive copies of mutable inputs with List.copyOf or clone, since a record is only shallowly immutable. The compiler assigns the fields after the body runs. Bean Validation annotations on components complement this for input-level rules, but core invariants belong in the constructor so that no invalid record can exist.

A record may declare additional, non-canonical constructors with different parameter lists, but each must begin by delegating with this(...) to another constructor, and the chain must end at the canonical constructor. That rule guarantees that every instance passes through the canonical or compact constructor, so its validation and normalisation can never be bypassed. A typical use is convenience parsing: Money(String amount, String currency) calls this(new BigDecimal(amount), Currency.getInstance(currency)). Additional constructors cannot assign fields themselves. Many teams prefer static factory methods such as Money.eur("10.00") instead, because they have descriptive names, can return cached instances and avoid ambiguity between overloaded constructors.

They are not generated as ordinary bytecode. javac emits a small method whose body is an invokedynamic instruction bootstrapped by java.lang.runtime.ObjectMethods.bootstrap, passing the record class, the component names and getters for the fields. On first call, the bootstrap builds method handles that compare or hash each component in order, using equals for references and the primitive comparisons for primitives, and toString produces Money[amount=10.00, currency=EUR]. After linking, the JIT inlines the result, so it performs like hand-written code. The advantage is smaller class files and the JDK's freedom to improve the implementation without recompiling records. You can still override any of the three explicitly.

Because records are deserialized through their canonical constructor. For an ordinary Serializable class, the JVM allocates the object without running its constructor and then writes field values straight from the stream, so a crafted stream can produce an object that violates every invariant, a well-known attack vector. For a record, the serialization mechanism reads the component values from the stream, matches them by name and calls the canonical constructor, so the compact constructor's validation and defensive copying run. Records also ignore custom readObject and writeObject hooks. This makes them a good choice for serialized messages, and the same principle applies when Jackson binds JSON to records.

Records fit everywhere the application handles data rather than identity. Typical uses are request and response DTOs in controllers, validated with Bean Validation annotations on the components; commands and domain events; query projections returned by Spring Data, including interface-free DTO projections from JPQL; @ConfigurationProperties classes, with defaults applied in the compact constructor; and value objects such as Money or DateRange inside the domain. They are a poor fit for JPA entities, which need a no-argument constructor, mutable state and proxies for lazy loading, and for Spring beans such as services, which have dependencies and behaviour rather than value semantics. Embeddables can be records since Hibernate 6.2.

Migrate incrementally, starting with simple immutable @Value classes that have no inheritance. Replace each with a record, move constructor validation into a compact constructor, and update callers from getX() to x(), which an IDE refactoring or OpenRewrite recipe can automate. Check framework support for each class: Jackson, MapStruct, Bean Validation and Spring binding all handle records in current versions, but older expression languages or reflection utilities may not. Keep Lombok or a plain class where you need inheritance, mutability, a large builder, or lazy fields. Records have no built-in builder or wither, so classes with many optional fields may stay as they are or use a small handwritten builder.

Data-oriented programming models data as plain, immutable values and keeps operations separate from them, which suits pipelines, messaging and domain alternatives. Records are the product types: a record holds a fixed combination of values, is immutable and transparent, and can be deconstructed with record patterns. Sealed interfaces are the sum types: a PaymentResult is exactly one of Approved, Declined or Pending. Pattern matching in switch then processes these alternatives exhaustively, so adding a new variant produces compile errors wherever it is not handled. The result is explicit domain modelling with compiler-checked completeness, a good complement to object orientation for boundaries, events and rules engines rather than a replacement for it.