Nest host validation vs NestHost attribute performed by Lookup::defineHiddenClass
peter.levart at gmail.com
Tue Oct 1 10:11:53 UTC 2019
I'm just an observer of this conversation, but I think I may have
something to add...
On 10/1/19 6:08 AM, Mandy Chung wrote:
> On 9/30/19 8:01 PM, John Rose wrote:
>> On Sep 27, 2019, at 3:46 PM, Mandy Chung <mandy.chung at oracle.com> wrote:
>>> I have a follow-up question w.r.t. JVMS 5.4.4 access control check
>>> (see #4 below). Below #1-3 is a summary with what we agree (please
>>> correct if anything is incorrect).
>>> 1. Hidden classes do not have names and they cannot participate in
>>> NH/NM attributes. These attributes in a hidden class are ignored
>>> and pretending not present.
>>> 2. LC::defineHiddenClass defines HNC as a nestmate of LC
>>> LC must be a nest host and full-power lookup which are required to
>>> authorize to add NHC as a member to the nest of LC.
>> This is wrong, I think. The asymmetry between nest host and nest
>> members is an artifact
>> of the static structure of the class file attributes (NH/NMs) and not
>> semantically significant
>> to access control (after validation).
I agree. Every member of a nest should have equal permissions. Promoting
NH to be more "equal" than the rest during runtime is wrong. It is wrong
also because of another aspect. There has been talk about
Class.getNestHost() being "dynamic", but Class.getNestMembers() to be
"static" only. And there was a dilemma of whether to return itself in
the Class.getNestMembers() for hidden classes.
I think there is no need to return hidden classes in the list of nest
members even for nests that consist of hidden class(es) only. I think
that even Class.getNestHost() should be "static" only. Imagine a
situation where a hidden class HC1 is defined in it's own nest. Then
this HC1 is used as a LC in a Lookup to define another hidden class HC2
to be part of this nest (HC1, HC2). What should HC2.getNestHost()
return? If it returns HC1, then HC2 is effectively preventing HC1 to be
But this is of course moot since what is the purpose of a nest
consisting of hidden classes only if they can not refer to each other
symbolically. Anyway, if above situation can be constructed, then there
is a problem. Would it make sense to only allow multi member nests if
they consist of at least one normal named class? Such nests always have
a named nest host, so Class.getNestHost() never returns a hidden class
different from this. If we only have nests consisting of:
1 - at least one named class; or
2 - a single hidden class
Then also Class.getNestMembers() could be "static" and simply return an
empty array for 2nd type of nests - this can always be interpreted as a
singular nest in program logic. But if it returns an array with one
member - this, it is also OK considering that it does not hold any other
hidden class accessible. It is just that is is not "consistent".
More information about the valhalla-dev