Review Request JDK-8244090: public lookup should find public members of public exported types

Mandy Chung mandy.chung at
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. 
Updated webrev:


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:
> Thanks
> Mandy

More information about the core-libs-dev mailing list