Reflection: how does one access a protected member in a superclass reflectively?
Jochen Theodorou
blackdrag at gmx.org
Tue Jan 16 21:08:28 UTC 2018
On 16.01.2018 20:38, John Rose wrote:
> On Jan 16, 2018, at 10:37 AM, Rony G. Flatscher <Rony.Flatscher at 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.
well said.
> 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.
which is a big deal of a problem if the class, that is supposed to be
exposed to the framework is not under the control of the framework. And
there is no good solution (rewriting the bytecode for example is no good
solution)
> 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.
Groovy is using that kind of logic in the initial invokedynamic
implementation. The problem is that Reflection allowed much more.
Frameworks (and whole languages) did grow around these capabilities. In
Java9 they have no alternative implementation anymore. And I'd like to
especially mention @CallerSensitive... This makes it very very difficult
for frameworks. The more general, the more you have to work around that
kind of logic - up to the point where no workaround is possible anymore
(short of opening for deep reflection, living with thousands of warnings
and an in acceptable commandline usage).
bye Jochen
More information about the jigsaw-dev
mailing list