Updated JEP: nestmates
forax at univ-mlv.fr
forax at univ-mlv.fr
Thu Apr 13 22:05:48 UTC 2017
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".
----- 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)
>> 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