With Valhalla, Java will have value classes that are shallowly immutable and do not have object identity, while ordinary identity classes remain mutable and support identity-based operations. Records are already shallowly immutable, so the main differences seem to be identity, reference equality, object layout, and possibly synchronization. That makes it unclear why someone would choose an identity record instead of a value record. Are there practical use cases for identity records, or should records eventually be value classes by default?
3 Answers
The default is largely a compatibility issue. Records were introduced before Valhalla, and their identity semantics are already part of Java's specification. Making existing records value types later would change the meaning of operations such as ==, identity hash codes, synchronization, and identity-based collections, potentially breaking programs even if most records never rely on identity. Keeping identity as the default avoids that silent change; developers who want value semantics can opt in explicitly.
Value and identity semantics also affect representation and performance. A small value record may be copied or stored inline efficiently, while a larger record may be better handled through references. The JVM optimizer can often eliminate unnecessary allocations or copies, so the best choice depends on field count, usage patterns, arrays, and object graphs. Identity records are therefore not only about synchronization; they can express that the reference itself has meaning.
Identity records still make sense when the object represents a distinct entity or needs a stable reference. Recursive structures such as tree nodes are a good example: a node can refer to other nodes, and identity semantics can make those relationships natural to represent. Identity can also matter for mutable auxiliary state, identity-based collections, or code that deliberately distinguishes two otherwise equal instances.
The important distinction is not simply mutability. A record can be immutable while still having identity, and copying a value can mean copying all of its fields rather than copying a reference. That difference matters for object graphs and larger record layouts.
It may feel verbose to add value to most records, but reversing the default would require an identity modifier instead and could break existing code. Java generally prefers preserving established defaults over changing them retroactively.