Draft JVMS changes for Nestmates

[Dan Smith]

> On Apr 19, 2017, at 12:45 AM, John Rose <john.r.rose at oracle.com> wrote:
> 
>  - NMs must be non-empty (degenerate nest is never explicit)
>  - NMs may not contain duplicates (cf. treatment of ClassFile.interfaces)
>  - NMs may not contain the current class (i.e., an index to a class with the same name as this_class)
>  - NMs may contain only package siblings (ditto)
>  - NMs and MoN may not refer to array classes (this is probably implied by the package prefix checks)

These are all do-able, but I'm not sure they're consistent with the spirit of JVMS in its treatment of attributes. We don't usually assert that lists are non-empty, don't contain duplicates, etc. (Granted, most attributes are not relevant to JVM execution.) You mention `interfaces`, but I don't see any such assertion in 4.1.

You can identify some package mismatches by looking at names, but not all (names with the same "package" name may be handled by different class loaders). I worry that making a partial effort here will give a false sense of security and lead someone in the future to see that as a bug and try to fully validate the package restriction.

I hate array "class names". Ugh. But, again, we're not generally concerned with that kind of hygiene in attributes.

>  - MoN may not contain the current class (ditto)
>  - MoN may contain only a package sibling (i.e., a referenced class name must have the same package prefix as this_class)
>  - NMs and MoN may not refer to array classes (this is probably implied by the package prefix checks)

If MoN names the current class, verification will fail (there's no matching NM attribute).

If MoN names a class in a different package, verification will fail (the rule checks "samePackageName").

If MoN names an array type, verification will fail (either due to the "samePackageName" check or because there's no matching NM attribute).

I don't see the benefit in making these "syntax" checks in addition to verification checks. (Even a class naming itself as its own superclass isn't a syntax error—it gets checked later.)

> David's prototype has the duplication check, and some of the other checks happen later.  I think they should all happen during class loading.

Something you might like is if we moved the MoN verification check out of verification (which is mainly concerned with Code attributes anyway) and into a late step of the class loading process (5.3.5)? Something like:

1) Get the bits
2) Parse the class
3) Load & validate superclasses
4) Load & validate interfaces
5) Load & validate MemberOfNest

—Dan