[External] : Re: JEP update: Value Objects

[John Rose]

On Dec 1, 2021, at 3:56 PM, John Rose <john.r.rose at oracle.com<mailto:john.r.rose at oracle.com>> wrote:

There is the converse problem that comes from the redundancy:
What happens if the class directly implements or inherits ValueObject
and ACC_VALUE is not set?  I guess that is an error also.

I hit send too soon:  That’s probably true for concrete classes.
For abstracts, ACC_VALUE must not be set (yes?) and ValueObject
“just flows” along with all the other super types, with no particular
notice.  It all comes together when ACC_VALUE appears, and that
must be on a final, concrete class.

I keep wondering what ACC_VALUE “should mean” for an abstract.
Maybe it “should mean” that the abstract is thereby also forced to
implement VO, so that all subtypes will be VO’s.

The slightly different meaning of ACC_PERMITS_VALUE is “hold
off on injecting IdentityObject at this point”.  Because the type
might allow subtypes that implement VO (whether abstract or
concrete).  At this point it also allows IdentityObject to be
introduced in subtypes.  Mmm… It could also have been
spelled ACC_NOT_NECESSARILY_IDENTITY.

As we said in the meeting, it seems to need magic injection of
IdObj, even if we can require non-magic explicit presence of VO.
Dan H., will the metadata pointer of IdObj be a problem to access,
if it is magically injected?