Draft JVMS changes for Nestmates

[David Holmes]

Hi Dan,

On 20/04/2017 2:06 AM, Dan Smith wrote:
>> On Apr 19, 2017, at 12:45 AM, John Rose <john.r.rose at oracle.com
>> <mailto: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.

The NestMembers duplicate check exists because I copied the spec and 
code from the InnerClasses attribute. 4.7.6 states the classes[] "must 
have exactly one corresponding entry ..." - hence a check for duplicates 
is done. I used the same language when I defined NestMembers. So the 
precedent does exist.

> 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 concur. We need the actual package check at nest-top validation time 
anyway, so checking this at parsing time seems pure overhead.

> 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

At present I do (5) during "linking" just prior to verification (in case 
verification  is disabled). It happens after the superclass and 
superinterfaces are themselves linked. But note that nest-top validation 
only requires the nest-top to be loaded, not linked.

David
-----

> —Dan