Updated JEP: nestmates

David Holmes david.holmes at oracle.com
Thu Apr 13 21:57:59 UTC 2017

On 14/04/2017 7:50 AM, Brian Goetz wrote:
>> The second part most certainly is necessary as a nest-top does not
>> itself have a nest-top!
> I would think we'd consider a nest-top as its own nest-top. That way,
> every nest has a top, which acts as a canonical element for that nest.

 From an implementation perspective certainly that simplifies 
nest-membership checks. but do you want that in the spec? Do you want 
javac to generate a self-referential MemberOfNest attribute? If you want 
this then the definitions need a rewrite. This is not where we are today.

>> It is not an optimization! You are either a nest-top (and so have a
>> NestMembers attribute) or you are a nested type and so have a
>> MemberOfNest attribute. (Of course you can be neither.)
> Similarly, I'd think that every class that has neither a NestMembers or
> MemberOfNest attribute constitutes a nest of one.

Sure logically you can consider it that way. Not sure it has any real 
affect on anything.

> Taken together, now:
>  - Every class belongs to exactly one nest;
>  - Every nest has a canonical, consistent nest-top (every member of the
> nest agrees on the nest top)


> This will become relevant when we extend this to support
> Lookup.defineClass with a private lookup, which has the effect of
> injecting a new class into an existing nest.  If every class is already
> in a nest, this injection is simplified.

I don't really see how it makes a difference, but you presumably have 
something in mind here.


More information about the valhalla-dev mailing list