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

Lois Foltan lois.foltan at
Wed Aug 12 21:13:26 UTC 2020

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:

Hi Mandy,

Still looks good!


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

More information about the core-libs-dev mailing list