Review Request JDK-8244090: public lookup should find public members of public exported types
mandy.chung at oracle.com
Tue Aug 11 18:00:40 UTC 2020
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.
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.
More information about the core-libs-dev