[External] : Re: JEP update: Value Objects

[John Rose]

On Dec 1, 2021, at 3:29 PM, Dan Smith <daniel.smith at oracle.com<mailto:daniel.smith at oracle.com>> wrote:

So we went down the path of "maybe there's no need for a flag at all" in today's meeting, and it might be worth more consideration, but I convinced myself that the ACC_VALUE flag serves a useful purpose for validation and clarifying intent that can't be reproduced by a "directly/indirectly extends ValueObject" test.

As you suggest, though, we could mandate that ACC_VALUE implies 'implements ValueObject’.

Assuming ACC_VALUE is part of the design, there are actually four
things we can specify, for the case when a class file has ACC_VALUE set:

A. Inject ValueObject as a direct interface, whether or not it was already inherited.
B. Inject ValueObject as a direct interface, if  it is not already inherited.
C. Require ValueObject to be present as a direct interface, whether or not it was already inherited.
D. Require ValueObject to be present as an interface, either direct or inherited.

A and B will look magic to reflection.
B is slightly more parsimonious and less predictable than A.
C and D are less magic to reflection, and require a bit more “ceremony” in the class file.
D is less ceremony than C.
Also, the D condition is a normal subtype condition, while the C condition is unusual to the JVM.

I guess I prefer C and D over A and B because of the reflection magic problem,
and also because of Dan H’s issue (IIUC) about “where do we look for the
metadata, if not in somebody’s constant pool?”

Since D and C have about equal practical effect, and D is both simpler to
specify and less ceremony, I prefer D best of all.

I agree that ACC_VALUE is useful to prevent “action at a distance”.

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.

— John