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