Splitting a new thread off from Dan's email about the jep draft to talk about the `aconst_init` bytecode:
> aconst_init, with a CONSTANT_Class operand, produces an instance of the named > value class, with all fields set to their default values. This operation > always has private access: a linkage error occurs if anyone other than the > value class or its nestmates attempts an aconst_init operation. Can you confirm if this is purely a rename of the previous defaultvalue / initialvalue bytecodes? I'm wondering how the name fits the eventual primitive values and their uses. Will they also use this bytecode or will they continue to use a defaultvalue version? The expected bytecode pattern for a "<new>" factory method is something like: aconst_init MyValue iconst1 withfield MyValue.x:I areturn Correct? --Dan On Mon, Nov 29, 2021 at 7:35 PM Dan Smith <daniel.sm...@oracle.com> wrote: > > 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. >
