[nestmates] validation of ClassFile for hidden classes

[David Holmes]

Hi John,

On 14/11/2019 5:47 am, John Rose wrote:
> On Nov 12, 2019, at 10:34 PM, David Holmes <david.holmes at oracle.com 
> <mailto: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 ears!  (…Eyes?)

If we dynamically inject the HC into a nest then the normal resolution 
of any NH/NM attribute (which must fail as you point out) will not 
actually occur. This ties into the notion of "runtime nest host" which 
has to be introduced into the spec in 5.4.4 to support dynamic nestmates 
- as outlined in other emails. That formulation previously assumed we 
were ignoring a NH/NM attribute in a HC, so now we are not ignoring them 
we just need to be sure that the formulation handles that case okay - 
which I think it does.

Cheers,
David

> 
> — John