Review Request JDK-8202113: Reflection API is causing caller classes to leak

Alan Bateman Alan.Bateman at
Mon Apr 30 11:39:29 UTC 2018

On 28/04/2018 10:44, mandy chung wrote:
> Webrev:
> The reflection machinery stores the caller class in each AccessibleObject
> such that it can skip the access check if access to a member has been
> verified for a given caller.  At the first time accessing the 
> AccessibleObject,
> it creates an Accessor object and then cache for subsequent use. This 
> cached
> Accessor object keeps a reference to the AccessibleObject object that
> will keep the caller class alive.
> The implementation has a root object for each AccessibleObject and
> the API returns a child object for users to access (that may suppress
> access check via setAccessible). The caller class is set in the cache
> of the child object.  This patch proposes to change ReflectionFactory
> newXXXAccessor methods to ensure to pass the root object rather than
> the child object.  The cache of the root object is always null.
The approach looks good, seems like this one was lurking (for protected 
members at least) for a long time.

The 3 x getRoot methods on ReflectAccess looks okay. An alternative 
would to create <T extends AccessibleObject> T getRoot(T obj) and a 
package private getRoot() method on AccessibleObject.

You might want to check AccessTest before pushing. The webrev shows very 
odd alignment, maybe tabs expanded to 8 space indent although it's not 
consistently so.


More information about the core-libs-dev mailing list