Agreed with Jason. It's okay to say thank you, but no thank you. A third party library maintainer, no matter how well-intentioned, has absolutely no say over the way I design, assemble, and run my operations. Reflection is risky, yes, but it's my risk to take. If I bust down the wrong wall and do something "wrong", that's my responsibility... but it's still my decision to make as a consumer.
Cheers, Paul On Thu, Jul 14, 2016 at 5:25 PM, Jason Greene <jason.gre...@redhat.com> wrote: > > > On Jul 14, 2016, at 5:07 PM, John Rose <john.r.r...@oracle.com> wrote: > > > > On Jul 14, 2016, at 4:51 AM, Andrew Haley <a...@redhat.com> wrote: > >> > >> Forgive me if I've missed something, but > >> #ReflectiveAccessToNonExportedTypes does not deal with the need to > >> make fields or methods accessible to the framework. That's what > >> setAccessible is used for. It would certainly be nice for a > >> framework to be able to say "make it accessible, but only to me." > > > > Saying setAccessible is like "borrowing" (without owner permission) a > > key to one locked door, if a non-public method is like a locked door. > > Not to sound like a broken record, but not all systems want the module to > control its own security. They want an intermediary. > > And that's a perfectly fine and reasonable security model. > > > > > Today's MethodHandles.Lookup object gives another way to open such > > doors. But you have to obtain the lookup object from a party that > already > > has access rights. It is like the owner of a building (a class) giving > a key > > which opens all the doors in the building, or all the doors not marked > "Private". > > > > With both setA Methods and Lookups, once you have the key in hand, > > you have to lock it up to prevent bad guys from stealing it from you. > > And if you loan it out, you have to loan it to trustworthy parties. > > > > Somewhere in between the two (unrestricted "borrowing" vs. direct > delegation > > of original access rights) must be some better conventions for > reflecting into frameworks. > > > > — John > > -- > Jason T. Greene > WildFly Lead / JBoss EAP Platform Architect > JBoss, a division of Red Hat > >
