Updated JEP: nestmates
david.holmes at oracle.com
Thu Apr 13 11:59:17 UTC 2017
On 13/04/2017 8:37 PM, Remi Forax wrote:
> Re-reading the spec again,
> i think it would be clearer if you introduce T the nest-top, and modifying the classloading order has to be listed in the "Risks and Assumptions" section.
> "The Java compiler compiles a group of nested types into a corresponding group of class files; it uses the InnerClasses and EnclosingMethod attributes to reify the nesting relationship (JVMS 4.7.6 and 4.7.7)."
> We can not re-use these attributes to describe nesting relationship because being part of a nest has to be verified, triggering classloading of the nest-top, thus changing the semantics of the existing attributes.
> "For types C and D to be nestmates they must either have the same nest-top T. A type C claims to be a member of the nest of D, if both C and D list T in their MemberOfNest attribute. The membership is validated during class loading if T also lists C and D in its NestMembers attribute. This may require loading of nest-top types earlier than might otherwise occur."
That paragraph in the JEP got modified slightly from my original. There
was no intent at that point to introduce a third type. My original is:
"For types <i>C</i> and <i>D</i> to be nestmates they must either have
the same nest-top, or else one must be the nest-top of the other. A type
<i>C</i> claims to be a member of the nest of <i>D</i>, if it lists
<i>D</i> in it's `MemberOfNest` attribute. The membership is validated
during class loading if <i>D</i> also lists <i>C</i> in its
`NestMembers` attribute. This may require loading of nest-top types
earlier than might otherwise occur."
Also note that "loading" is being used to allow some flexibility. What I
currently do is validate during class linking, prior to verification (if
enabled). But specifying it to happen at that exact point may be too
> A type classfile has zero or one MemberOfNest attribute and zero or one NestMembers. So a type can only be part of zero or one nest.
But it can not have both a MemberOfNest and a NestMembers attribute.
> Risks and Assumptions
> This proposal modifies the classloading order because a nest-top of a type needs to be loaded either eagerly when a member of a nest is loaded or more lazily when a member of a nest try to access to another member of a nest.
The interesting case is where the nest-top class never actually gets
used in the execution of the application, and so presently is not
loaded. I've encountered several tests that fail because they are now
forced to load the nest-top class but can't locate it due to the way the
test has arranged classes on boot/classpath or via classloaders. In
those cases it makes no difference how eagerly or lazily you load the
> This is not a problem for an inner-class because it also has a reference to the enclosing class, so the nest-top class is already loaded, for non inner class (static enclosed class), it will depend on the java compiler implementation, i.e. if the compiler eagerly add nestmates that mirror the InnerClasses attribute even if the enclosed class/interface do not access to a nestmate member or if the compiler add nestmates to the nest only when necessary (like currently it only generates bridges when necessary).
Yes a compiler could elide the nest attributes if being nestmates is not
relied upon by the code. But to the VM they would not be nestmates so
any dynamic lookup that required nestmate access would fail.
> ----- Mail original -----
>> De: "Brian Goetz" <brian.goetz at oracle.com>
>> À: valhalla-dev at openjdk.java.net
>> Envoyé: Mercredi 12 Avril 2017 23:28:17
>> Objet: Updated JEP: nestmates
>> The "Nestmates" JEP has been updated:
More information about the valhalla-dev