Alternative mechanism for reflective access control (#ReflectiveAccessToNonExportedTypes / #AwkwardStrongEncapsulation)

Andrew Dinn adinn at
Wed Sep 28 12:22:51 UTC 2016

On 28/09/16 13:01, Alan Bateman wrote:
> In general then I think that we need to find ways to reduce the use of
> setAccessible over time. We really need a long term plan to degrade,
> deprecate and eventually remove it. This would of course mean working on
> some challenging problems and use-cases.
> So what would the alternative to setAccessible be? It would be nice if
> the framework libraries (you mention ORM tools and maybe the Hibernate
> ORM devs could be the guinea pig) would start to make use of the "new
> reflection API" that is java.lang.invoke. So rather than bypassing
> access checks with legacy core reflection then they would instead use
> MH.Lookup objects as capabilities. Think code in a consumer module
> creating a Lookup object with the appropriate lookup class + mode that
> it cooperatively hands to the framework. This puts the access check in
> the consumer module so that the frameworks don't need to break in. This
> direction isn't without challenges of course as there may be
> initialization issues to deal with. It might, for example, involve
> injecting helper code into a submissive consumer module when there isn't
> explicit initialization. John Rose has good write-ups in JIRA with ideas
> in this area.

I'd be happy to try to conduct such an experiment. Can you provide links
to the relevant JIRAs.


Andrew Dinn
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander

More information about the jigsaw-dev mailing list