JEP update: Value Objects

[Dan Heidinga]

>
> 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