I've been exploring possible terminology for "Bucket 2" classes, the ones that lack identity but require reference type semantics.
Proposal: *value classes*, instances of which are *value objects* The term "value" is meant to suggest an entity that doesn't rely on mutation, uniqueness of instances, or other features that come with identity. A value object with certain field values is the same (per ==), now and always, as every "other" value object with those field values. (A value object is *not* necessarily immutable all the way down, because its fields can refer to identity objects. If programmers want clean immutable semantics, they shouldn't write code (like 'equals') that depends on these identity objects' mutable state. But I think the "value" term is still reasonable.) This feels like it may be an intuitive way to talk about identity without resorting to something verbose and negative like "non-identity". If you've been following along all this time, there's potential for confusion: a "value class" has little to do with a "primitive value type", as we've used the term in JEP 401. We're thinking the latter can just become "primitive type", leading to the following two-axis interpretation of the Valhalla features: --------------------------------------------------------------------------------------------- Value class reference type (B2 & B3.ref) | Identity class type (B1) --------------------------------------------------------------------------------------------- Value class primitive type (B3) | --------------------------------------------------------------------------------------------- Columns: value class vs. identity class. Rows: reference type vs. primitive type. (Avoid "value type", which may not mean what you think it means.) Fortunately, the renaming exercise is just a problem for those of us who have been closely involved in the project. Everybody else will approach this grid with fresh eyes. (Another old term that I am still finding useful, perhaps in a slightly different way: "inline", describing any JVM implementation strategy that encodes value objects directly as a sequence of field values.) Here's a new JEP draft that incorporates this terminology and sets us up to deliver Bucket 2 classes, potentially as a separate feature from Bucket 3: https://bugs.openjdk.java.net/browse/JDK-8277163 Much of JEP 401 ends up here; a revised JEP 401 would just talk about primitive classes and types as a special kind of of value class.
