Draft JVMS changes for Nestmates
david.holmes at oracle.com
Thu Apr 20 03:38:18 UTC 2017
On 20/04/2017 2:47 AM, Dan Smith wrote:
>> On Apr 19, 2017, at 8:12 AM, Brian Goetz <brian.goetz at oracle.com> wrote:
>>> Yep. Also, multiple classes can claim the same nest member class in their NestMembers attributes. Not a problem as long as the MemberOfNest attribute (if any) of the member class points to a host class that claims it.
>> At the risk of bikeshedding, I find the names NestMembers and MemberOfNest confusing; I keep having to think about the directionality, since they sound so similar. Would be good to find names that have obviously opposite directionality.
>> A not-very-good suggestion (but which illustrates the directionality thing I'm going for) would be "NestDeclaration" and "NestUse". It's pretty clear which is which without thinking about it.
>> Perhaps: NestHost and NestMember ?
> I also don't love that "NestMembers" seems more authoritative than it really is. (Doesn't get validated, doesn't suggest that other classes can be dynamically added.)
> Something like "AllowedInNest" would better convey the actual meaning of that attribute.
I don't see how AllowedInNest is any less authoritative sounding than
NestMembers. Neither suggests other classes may be added dynamically -
nor should they in my opinion. These are static attributes of a
classfile defining a relationship as it was known to exist when the
classfile was created. Any dynamic means to add to a nest at runtime
would not be modifying the classfile NestMembers attribute, but the
runtime representation thereof. I suppose InitialNestMembers may capture
this more accurately - though it does then beg the question as to how to
add the to set later.
Aside: when first discussed in the context of generic specialization I
assumed the NestMembers entry would be a "wildcard" which indicated that
not only was the named generic type a nestmember, but all
specializations thereof (which would presumably have a name derived from
the base generic type). But in the context of Lookup.defineClass I have
no idea how it is/was expected that nest membership would expand - or
how the validity of doing so would be established.
More information about the valhalla-spec-observers