> > 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. >
Reading through this I see that ACC_VALUE classes implicitly implement ValueObject: > class file representation & interpretation > > A value class is declared in a class file using the ACC_VALUE modifier > (0x0100). At class load time, the class is considered to implement the > interface ValueObject; an error occurs if a value class is not final, has a > non-final instance field, or implements—directly or indirectly—IdentityObject. I'll reiterate my earlier pleas to have javac explicitly make them implement ValueObject. The VM can then check that they have both the bit and the interface. It's a simpler model if the interface is always there for values as the VM won't have to track whether it was injected for a value class or explicitly declared. Why does that matter? For two reasons: JVMTI will need to be consistent in the classfile bytes it returns and not included the interface if it was injected (less tracking), and given earlier conversations about whether to "hide" the injected interface from Class::getInterfaces, always having it for values removes one more sharp edge. --Dan
