Nest host validation vs NestHost attribute performed by Lookup::defineHiddenClass
mandy.chung at oracle.com
Wed Sep 25 18:26:22 UTC 2019
On 9/24/19 8:41 PM, John Rose wrote:
> On Sep 24, 2019, at 8:14 PM, Mandy Chung <mandy.chung at oracle.com> wrote:
>> Hidden classes do not have names and they cannot participate in NH/NM attributes as you noted (2a) in your previous reply. Why not disallowing defining a hidden class with NH/NM attributes as in the current proposal ?
> That’s fine too. But I think it makes the spec a little simpler to say that (a) they are erroneous and (b) they are therefore ignored, rather than adding a special check and a special failure mode, just for HCs.
Yes this is a simplification. To capture the core reflection API for
Class::getNestHost always returns this class if this class is a hidden
class. This is good.
Core reflection API presents the static view of what's in the classfile
(with some exception - Class::getNestHost).
If this class is a hidden class with NM attribute, Class::getNestMembers
throws LinkageError as the static nest membership validation on each
member fails - this is consistent when this method is called for an
ordinary class with bad entry in NM attribute.
Another relevant note to capture here (about `EnclosingMethod` and
A hidden class having `EnclosingMethod` attribute and `InnerClasses`
attribute describing this hidden class as an enclosing class or as an
immediate member is also erroneous. (A hidden class should always be a
top level class and there is no nested hidden class in JLS terms. If a
hidden class could be nested, then its enclosing class would need to
refer to it by name, which is impossible.)
dHC does not do any special checking. Instead core reflection API such
as Class::getDeclaringClass, getDeclaredClasses etc will throw an exception.
More information about the valhalla-dev