jdk.internal.reflect.ReflectionFactory and SecurityManager

Peter Levart peter.levart at gmail.com
Mon Dec 26 19:29:36 UTC 2016


There are 2 ReflectionFactory classes in JDK 9. The old one is 
sun.reflect.ReflectionFactory which ended in jdk.unsupported module and 
to which access is restricted with SecurityManager. There is also new 
jdk.internal.reflect.ReflectionFactory which is used internally by JDK, 
is exported to internal modules only but still uses SecurityManager to 
restrict access to itself. I checked all usages and they all use 
AccessControler.doPrivileged() for obtaining the instance of 
jdk.internal.reflect.ReflectionFactory, which somehow defeats the 
purpose of SecurityManager access checks in this API.

I think this could be simplified by removing the SecurityManager check 
from jdk.internal.reflect.ReflectionFactory#getReflectionFactory static 
method and change all usages to invoke this method directly without 
doPrivileged(). There are already two sensitive internal APIs exposed 
without SecurityManager checks: jdk.internal.misc.Unsafe#getUnsafe and 
various jdk.internal.misc.SharedSecrets#getXxxAccess methods. So why 
wouldn't internal ReflectionFactory be exposed the same way?

This would make obtaining the ReflectionFactory more robust and not 
sensitive to bootstrap issues that surfaced recently after my push of a 
fix for issues 8062389, 8029459, 8061950.

So, what do you think? Is this a worthwhile cleanup and simplification?

Regards, Peter

More information about the core-libs-dev mailing list