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

[Andrew Dinn]

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.

regards,


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