On 8/11/2020 2:00 PM, Mandy Chung wrote:
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
Hi Mandy,
Still looks good!
Thanks,
Lois
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
