It was agreed in an offline discussion with Lois, Kim and John that this
work should wait for the integration of JDK-8247938 and JEP 347 Enable
C++ 14 features.
This patch is updated to use scoped enum consistent with JDK-8247938.
Updated webrev:
http://cr.openjdk.java.net/~mchung/jdk16/webrevs/8244090/webrev.01/index.html
Thanks
Mandy
On 6/18/20 2:12 PM, Mandy Chung wrote:
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
