Lookup.findStatic() triggers verification of nestmates attribute too early ?

[John Rose]

On Apr 15, 2020, at 5:41 AM, Remi Forax <forax at univ-mlv.fr> wrote:
> 
> i've discovered that using Lookup.findStatic() triggers the verification that the attributes NestHost and the NestMembers are compatible.
> 
> I believe it's a bug, the equivalent code using bytecodes will no trigger this early verification, the verification is done lazily when a private member of a class of the nest is accessed the first time.

I don’t think it’s a bug, if the JVMS fine print says what I think it says.
Nestmate checking is done when a nominal bytecode is resolved, not as
part of its post-resolution semantics.  The rules that say a class is initialized
lazily on first static access (call or variable access or instance creation)
are not organized as part of the resolution semantics of those instructions,
but as part of their run-time semantics.  Meanwhile, all relevant resolution
work is done in Lookup::findX calls, before those calls return.  It’s not right
for the invocation of a method handle *ever* to throw a resolution error;
all those checks must be done before the MH is created.  But nest mate
checking is done for resolution (as part of JVMS 5.4) not initialization
(JVMS 5.5).

As a matter of design, any error which is documented as a “Linking
Exception” in the JVMS (chapter 6) must be completed before the Lookup
API call returns a MH.  Any error documented as a “Run-time Exception”
must be performed after the MH is invoked.  Those run-time exceptions
include any which arise from lazy initialization of classes that are targeted
by Xstatic bytecodes.

https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-6.html#jvms-6.5.invokestatic

So, yes the Lookup.findStatic call needs to explore nestmate relations.
And no it cannot defer those until the first call of the resulting MH,
analogously to lazy <clinit> execution.  Was that what you were expecting,
or did I misread your report?

— John