Review Request JDK-8202113: Reflection API is causing caller classes to leak
Alan Bateman
Alan.Bateman at oracle.com
Mon Apr 30 11:39:29 UTC 2018
On 28/04/2018 10:44, mandy chung wrote:
> Webrev:
> http://cr.openjdk.java.net/~mchung/jdk11/webrevs/8202113/webrev.00/
>
> 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.
-Alan
More information about the core-libs-dev
mailing list