Hi John,
Aside: my replies to the experts list are held up for moderation.
On 19/04/2017 4:45 PM, John Rose wrote:
On Apr 18, 2017, at 1:49 PM, Dan Smith <daniel.sm...@oracle.com
<mailto:daniel.sm...@oracle.com>> wrote:
On Apr 18, 2017, at 2:12 PM, Remi Forax <fo...@univ-mlv.fr
<mailto:fo...@univ-mlv.fr>> wrote:
Verification of MemberOfNest
I include a discussion block about different options of validating
MemberOfNest.
I think the consensus, and my preference, is to do it during
verification of
the member class. (NestMembers, on the other hand, is never
validated, except
as a side-effect of checking MemberOfNest.)
It means that a NestMembers can contains Class that are not yet/never
defined.
It's not a problem for me.
Yep. Also, multiple classes can claim the same nest member class in
their NestMembers attributes. Not a problem as long as the
MemberOfNest attribute (if any) of the member class points to a host
class that claims it.
We need to specify more structural constraints on the new attributes.
If we make them more strongly normalizing, there will be fewer chances
for semantic bugs on unexpected inputs. Also, making them structural
constraints means we check them early, during class file loading.
These are good, I think:
- 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)
- 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 may contain only package siblings (ditto)
- NMs and MoN may not refer to array classes (this is probably implied
by the package prefix checks)
You already covered:
- a class may have exactly one or zero of NMs or MoN (no double dipping
of any kind)
- NMs and MoN may only have CONSTANT_Class attributes (implies no
nulls, well-formed names)
David's prototype has the duplication check, and some of the other
checks happen later. I think they should all happen during class loading.
Some of these are a lot more awkward to do during classfile parsing and
will require symbol comparisons. I was wanting to avoid "deep
validation" of NMs as it penalizes all the good code. Having a "bad" NM
entry seems harmless as these entries are only used to validate the
initial claim of nest membership. If an entry is "bad" then by
definition it will not match with any claimee.
David
-----
— John
