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