Updated JEP: nestmates

[forax at univ-mlv.fr]

I'm fine with that, 
we can still comeback to that option latter if loading the nest-top during the parsing cause too much breakage with the existing application. 

Rémi 

> De: "John Rose" <john.r.rose at oracle.com>
> À: "Rémi Forax" <forax at univ-mlv.fr>
> Cc: "David Holmes" <david.holmes at oracle.com>, "Brian Goetz"
> <brian.goetz at oracle.com>, valhalla-dev at openjdk.java.net
> Envoyé: Vendredi 14 Avril 2017 22:40:43
> Objet: Re: Updated JEP: nestmates

> On Apr 13, 2017, at 3:21 PM, forax at univ-mlv.fr wrote:

>> Being lazier than linking time in my mind means doing the check at runtime the
>> first time you access to the member.

> That's an option. I kind of like that, but there's a cost: You can get strange
> failures
> as a side effect of access checking. I ran into this when prototyping nest
> access
> checking on top of InnerClasses. The internal JVM paths, in HotSpot, don't
> provide
> for such errors bubbling up from access checking, nor do they provide for logic
> that says "drop what you are doing and try to load a random class, right now".
> In pathological cases you might start to see deadlocks.

> So I'm actually more comfortable with loading the nest-top no later than linking
> (i.e., verifying or preparing) any of its nestmates. Can we get away with that?

> — John