JLS spec changes for nestmates

[David Holmes]

On 19/12/2017 6:53 AM, Dan Smith wrote:
>> On Dec 17, 2017, at 6:15 PM, David Holmes <David.Holmes at oracle.com> wrote:
>>
>>> I looked over 13.1, and think it does a fine job of allowing binaries to use the NestHost and NestMembers attributes without any changes (see items 9 and 10 in the second list).
>>
>> I don't follow. Items 9 and 10 seem to pertain to the InnerClasses attribute. NestHost and NestMembers can not, in general, be used to convey the information required by items 9 and 10. The NestHost attribute need not refer to the immediately enclosing class. The NestMembers attribute only appears in the top-level NestHost class.
> 
> Yeah, you're right. This section is very hand-wavy, so I tend to give it some latitude to say things that aren't exactly right. And there's a difference between _allowing_ a reference to something and _requiring_ it. But we could probably do a better job here and require the references we expect to appear in NestHost/NestMembers.

But I didn't think it was a requirement to use the new attributes. I 
thought a source compiler could choose to continue to generate bridge 
accessors and not need the new attributes? (That's what the JEP implies.)

David
-----

> 
> 9. Every nested class and nested interface must have a symbolic reference to its immediately enclosing class (§8.1.3) **and, if different, the top-level type that encloses the class or interface**.
> 
> 10. Every class must contain symbolic references to all of its member types (§8.5), and to all local and anonymous classes that appear in its methods, constructors, static initializers, instance initializers, and field initializers.
> 
> Every interface must contain symbolic references to all of its member types (§9.5), and to all local and anonymous classes that appear in its default methods and field initializers.
> 
> **If the class or interface is a top-level type declaration, it must contain symbolic references to all other classes or interfaces declared in its body and nested within other type declarations.**
> 
> —Dan
>