[External] : Re: JEP update: Value Objects

[Remi Forax]

> From: "John Rose" <john.r.rose at oracle.com>
> To: "daniel smith" <daniel.smith at oracle.com>
> Cc: "Dan Heidinga" <heidinga at redhat.com>, "valhalla-spec-experts"
> <valhalla-spec-experts at openjdk.java.net>
> Sent: Jeudi 2 Décembre 2021 00:56:02
> Subject: Re: [External] : Re: JEP update: Value Objects

> On Dec 1, 2021, at 3:29 PM, Dan Smith < [ mailto:daniel.smith at oracle.com |
> 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.

As Daniel said during the meeting and in a following email, from the POV of javac, the compiler should add "implements ValueObject" on all concrete value classes even if ValueObject is already present in the hierarchy to avoid action at distance (to detect when a super type change from implementing ValueObject to implement IdentityObject by example). With that requirement, for the VM, D and C are equivalent for all classes generated by javac. 

So D is Ok. 

Rémi 

> — John