Updated JEP: nestmates

[forax at univ-mlv.fr]

It seems we are all on the same page but some of us talk about the spec and other about the implementation.

>From the spec point of view, i agree with Brian,
"Every class belongs to exactly one nest",
- if there is a MemberOfNest attribute, it defines the nest,
- if there is a NestMembers attribute, it defines the nest-top,
- if there is no attribute, it defines its own nest.
and "Every nest has a canonical, consistent nest-top".

Rémi

----- Mail original -----
> De: "David Holmes" <david.holmes at oracle.com>
> À: "Brian Goetz" <brian.goetz at oracle.com>, forax at univ-mlv.fr
> Cc: "John Rose" <john.r.rose at oracle.com>, valhalla-dev at openjdk.java.net
> Envoyé: Jeudi 13 Avril 2017 23:57:59
> Objet: Re: Updated JEP: nestmates

> 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)
> 
> Yes.
> 
>> 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.
> 
> Thanks,
> David