[nestmates] validation of ClassFile for hidden classes

David Holmes david.holmes at oracle.com
Thu Nov 14 04:49:28 UTC 2019


Hi John,

On 14/11/2019 1:49 pm, John Rose wrote:
> On Nov 13, 2019, at 6:10 PM, David Holmes <david.holmes at oracle.com 
> <mailto:david.holmes at oracle.com>> wrote:
>>
>> 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.
> 
> Right, that makes sense, and now I see where you are coming from
> about ignoring those attributes.  If the dynamic host is consulted
> *instead* of the NestHost and NestMembers attributes, for both link
> resolution and for reflection, *and* if there is no other use of
> those attributes, then they can truly be said to be “ignored”.
> 
> In my view the statement that NH/NMs are ignored is explanatory, not
>  normative, because it is a corollary of the normative rules which
> pertain to NH and NMs and the preferential use of the dynamic host
> property when performing link resolution and reflection.
> 
> My next question:  Where is the most recent draft of the
> specification of link resolution and reflection of hidden classes
> which are injected into nests? Does the JVMS get a tweak, since it
> only talks about the attributes?
There is a task for updating the JVMS for hidden classes, including the 
dynamic nestmate aspect:

https://bugs.openjdk.java.net/browse/JDK-8231313

I just updated with my suggestions regarding dynamic nestmates, 
previously expressed in email with Mandy and Alex. But I note that 
suggestion doesn't quite do what was just discussed:

"The runtime nest host of a class C is its static nest host if that can 
be resolved without error, else C itself if the static nest host cannot 
be resolved without error, else the nest host of the nest the class was 
programmatically defined to be a member of."

We would want the programmatic nesthost to take precedence, then try to 
resolve the static NH etc.

Not sure if Mandy has the reflection aspect documented outside of email 
at the moment.

David
-----

> — John
> 
> P.S. I also dumped some thoughts about classData on
> https://bugs.openjdk.java.net/browse/JDK-8171335
> some of which relate to nestmate considerations.



More information about the valhalla-dev mailing list