On Jan 16, 2018, at 10:37 AM, Rony G. Flatscher <rony.flatsc...@wu.ac.at> wrote: > > Well that is probably the core of the problem: who needs to be the subclass, > the reflector or the > object to be reflected upon (whose inheritance tree is being walked up > towards the root class, and > if public or protected members are found reflectively accessed)?
Quick comment: With the core reflection API, the reflector's permissions are derived from the reflector, not the class being investigated. This works fine when a class reflects itself but is not so good for frameworks. The reflection API in java.lang.invoke, though more limited, does support rights delegation through the Lookup object. This means that your "patient" class doesn't need to do the reflection work; it can merely create a private lookup in itself and hand it to the framework, which can do the reflection on behalf of the patient. You can even mix the old and new mechanisms (a point I don't think I've seen on this thread, although I haven't read it all). Given a private lookup object in some patient P, a framework class F can create a method handle on a core reflection API point that is @CallerSensitive (like Class.forName, etc. etc.) which allows F to call that API point with the same rights as P, not F. HTH — John
