Updated JEP: nestmates
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