<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div><blockquote type="cite" class=""><div class="">On Apr 19, 2017, at 12:45 AM, John Rose <<a href="mailto:john.r.rose@oracle.com" class="">john.r.rose@oracle.com</a>> wrote:</div><div class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""> - NMs must be non-empty (degenerate nest is never explicit)</div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""> - NMs may not contain duplicates (cf. treatment of ClassFile.interfaces)</div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""> - NMs may not contain the current class (i.e., an index to a class with the same name as this_class)</div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""> - NMs may contain only package siblings (ditto)</div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""> - NMs and MoN may not refer to array classes (this is probably implied by the package prefix checks)</div></div></blockquote><div><br class=""></div>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.</div><div><br class=""></div><div>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.</div><div><br class=""></div><div>I hate array "class names". Ugh. But, again, we're not generally concerned with that kind of hygiene in attributes.</div><div><br class=""></div><div><div><blockquote type="cite" class=""><div class=""> - MoN may not contain the current class (ditto)</div><div class=""> - MoN may contain only a package sibling (i.e., a referenced class name must have the same package prefix as this_class)</div></blockquote><blockquote type="cite" class=""><div class=""> - NMs and MoN may not refer to array classes (this is probably implied by the package prefix checks)</div></blockquote><div class=""><div class=""><br class=""></div></div><div class=""><div class="">If MoN names the current class, verification will fail (there's no matching NM attribute).</div></div><div class=""><br class=""></div><div class="">If MoN names a class in a different package, verification will fail (the rule checks "samePackageName").</div><div class=""><br class=""></div><div class="">If MoN names an array type, verification will fail (either due to the "samePackageName" check or because there's no matching NM attribute).</div><div class=""><br class=""></div><div class="">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.)</div><div class=""><br class=""></div></div><blockquote type="cite" class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">David's prototype has the duplication check, and some of the other checks happen later.  I think they should all happen during class loading.</div></blockquote><div><br class=""></div></div>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:<div class=""><br class=""></div><div class="">1) Get the bits</div><div class="">2) Parse the class</div><div class="">3) Load & validate superclasses</div><div class="">4) Load & validate interfaces</div><div class="">5) Load & validate MemberOfNest</div><div class=""><br class=""></div><div class="">—Dan</div></body></html>