[nestmates] setAccessible(true) restriction on hidden classes

John Rose john.r.rose at oracle.com
Wed Sep 11 04:11:21 UTC 2019


On Sep 10, 2019, at 4:27 PM, Mandy Chung <mandy.chung at oracle.com> wrote:
> 
> One restriction we proposed for hidden class is that it does not allow setAccessible(true) on members of hidden classes.  This ensures that private internals of a language runtime are not accessible from outside the implementation.
> 
> The compatibility concern seems to be higher than what we anticipated.  Libraries reflecting on lambda proxy classes and calls setAccessible(true) on their members unconditionally are impacted by this.  Our testing shows that cassandra uses MemoryMeter library that does this.
> 
> setAccessible can suppress language access check only if the declaring class is in the same module as the caller or the package of the declaring class is not open to the caller's module.  To mitigate the incompatibility concern, I propose to relax the restriction on hidden classes and follow the existing setAccessible rules.  If a hidden class is injected in a package that is open to the caller for deep reflection, setAccessible(true) will succeed.

I think this is reasonable.  Hidden classes are hidden in that they cannot be discovered by name.
Once a hidden class is discovered via reflection (getClass, mainly) we can discuss further “hidings”
that might occur, such as sealing up the field or method list from reflection or access, but that would
be a separate feature.  A “locked class”, say.  I see no reason why a hidden class must be "locked"
(in this sense), and you’ve discovered reasons not to link the concepts.  So let’s separate them.

Thanks for the write-up.
— John





More information about the valhalla-dev mailing list