Draft JVMS changes for Nestmates

[David Holmes]

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.

David

> —Dan
>