[nestmates] validation of ClassFile for hidden classes
john.r.rose at oracle.com
Wed Nov 13 19:47:11 UTC 2019
On Nov 12, 2019, at 10:34 PM, David Holmes <david.holmes at oracle.com> wrote:
> I see from discussion on the experts list that there is move to not reject a classfile based on the semantics of attributes, so not ignoring/rejecting during classfile parsing is okay. But the specification will still have to address the interaction between static NestHost attribute and the use of dynamic nestmate injection.
The *normative* parts of the spec. already do address this interaction, as a corollary of the
rules for normal classes (as applied to hidden classes).
Here’s the reasoning: A NH attribute is futile (confers no additional access) in the case
where the the class containing the NH and the actual intended NH (however that is
determined) cannot symbolically resolve each other. There is a similar point for any
*element* of a NMs attribute. Basically, nestmates are always able to name each
other. The corollary to this for HCs is that a HC cannot benefit in any way from
either a NMs or a NH attribute; such attributes are futile in exactly the same way
that they would be on “broken” regular classes. There is thus no need to special
case the interaction of HCs with these attributes.
So you need to do a little theorem-proving to derive the behavior of NH on a HC, but
it’s not too hard, and perfectly sound, and thus no new normative language is needed.
Or so I think.
OTOH, the spec. *does* deserve a bit of non-normative commentary observing the corollary.
I assume you and I are in agreement here, but if you know a fault in my reasoning I’m all
More information about the valhalla-dev