Modelling

Lookup sheet for stage 2. The question it exists to answer: which construct should model this, and what does choosing it commit me to?

Choosing the construct

What a record generates

equals on a double component follows Double's boxed semantics rather than ==: two NaN values compare equal, and -0.0 does not equal 0.0. An array component breaks both equals (identity, not content) and toString (no contents shown), since a record does not special-case arrays. A compact constructor that copies a mutable component on the way in stops the leak from the constructor argument; it does nothing about the generated accessor still handing back the same mutable field, which needs its own override to close.

Construction order

1. The superclass constructor runs to completion first, including its own field initialisers and instance initialiser blocks.
2. This class's field initialisers and instance initialiser blocks run, in source order, interleaved exactly as written.
3. The constructor body runs last.

Consequence: a superclass constructor that calls a method the subclass overrides sees that override read the subclass's own fields still at their default, because the subclass's field initialisers have not run yet.

The override does not run between the numbered steps, it runs inside step 1, and step 2 is what would have given the field its value. That ordering is why calling an overridable method from a constructor is a defect rather than a style preference: no amount of care in the subclass can fix it, because the subclass has not started yet.

Overriding rules

Inheritance smells and their replacement

Pattern matching forms

Exhaustiveness

default may be omitted when either holds:

• the selector's type is sealed and every permitted subtype has a case
• the selector is an enum and the switch is an expression covering every constant

Enum facts worth looking up

valueOf(String) throws IllegalArgumentException: No enum constant Type.name on an unknown name; store name() if a value must survive a redeclaration, since a rename is at least visible in the diff that caused it.

Generics

Erasure removes the type argument at run time, so List<String> and List<Integer> share one Class object, and every rule below follows from there being nothing left to check against:

A raw type switches checking off entirely instead of failing: warning: [unchecked] unchecked call to add(E) as a member of the raw type List. Reach for a Class<T> token when a genuine run-time type is needed, to validate a cast or drive a reflective construction, since erasure has already thrown the compile-time T away by the time the program runs.

The immutability recipe

• No setters, and no other method that mutates state after construction.
• Every field final.
• The class itself final, or sealed with permitted subtypes that keep the same discipline.
• A defensive copy of any mutable argument on the way in.
• A defensive copy or an unmodifiable view of any mutable field on the way out, meaning the accessor, not only the constructor.
• No reference to the object escaping before its constructor finishes.

A record supplies every line except the copying, both directions, which is why a List or array component is the recipe's most common gap.

Neither one touches the elements: an unmodifiable list of mutable elements still lets every element change, since the list only ever refused writes to itself.

Feature to release

Sources

• JLS Chapter 8, Classes
• JLS 8.4.8, Inheritance, Overriding, and Hiding
• JLS 8.9, Enum Classes
• JLS 8.10, Record Classes
• JLS Chapter 9, Interfaces
• JLS 4.6, Type Erasure
• JEP 395, Records
• JEP 409, Sealed Classes
• JEP 441, Pattern Matching for switch
• Record
• Enum
• List
• Class