Prior to JDK-8173978, publicLookup().in(C.class) produces a Lookup
object on C with PUBLIC access which can be used to look up
unconditionally exported public types from the module of C. Such lookup
can only look up this C class defined by loader 1 but not another class
named "C" defined by loader 2.
JDK-8173978 adds the support for cross-module teleporting.
publicLookup().in(C.class) was changed to produce a public Lookup i.e.
with UNCONDITIONAL access. A public lookup should be able to look up
public members of any unconditionally exported public types including a
class named "C" loaded by different loaders. It reveals a bug in VM
resolution for Lookup API that adds the loader constraints with
java.lang.Object as the accessor that constraints a public lookup to
load one type named C but any more.
The lookup class of a public lookup is irrelevant to the lookup
context. Type consistency on P/Q/R live Class objects from the given
MethodType (MT)is ensured at the following:
1. P/Q/R are consistent from the loader of the declaring class of the
resolved member (D's loader)
2. P/Q/R are consistent w.r.t. the invoking class and the caller's MT at
invocation time (the method handle carries the caller's MT that will be
verified).
The loader constraints added for public lookup is not necessary and adds
undesirable constraints. The proposed fixis to skip adding loader
constraints if the lookup mode is either TRUSTED or UNCONDITIONAL.
Webrev:
http://cr.openjdk.java.net/~mchung/jdk16/webrevs/8244090/webrev.00/index.html
Thanks
Mandy
