Reflection: how does one access a protected member in a superclass reflectively?

[Rony G. Flatscher]

On 17.01.2018 14:12, Alan Bateman wrote:
> On 17/01/2018 12:18, Rony G. Flatscher wrote:
>> :
>>
>> The reflection logic in the bridge is (simplified) as follows:
>>
>>   * use the object's 'o' class and look up its declared methods or fields, analyze further, if
>>     member is 'public', otherwise
>>
>>       o iterate over all of its superclasses looking up in each class all declared methods or
>>         fields, analyze further, if member is 'public' *or* 'protected' (looking up a superclass
>>         'protected' is regarded to be 'public' for the subclass) and, if a matching member is
>>         found, carry out the operation (in this case a Field.get()) and return its value
>>
>> This way it is assured that the users of the bridge are never able to get at private or package
>> private members (nor that they are able to invoke a protected member in the object's type itself).
>>
> Accessibility has been significantly upgraded in Java SE 9. "public" used to imply accessible to
> everyone, now we have "public to everyone", "public to friend modules" or "public within a
> module".  If you want the above logic to work with modules then it will need to be updated to
> handle classes in named modules. It will essentially amount to overhauling the above to find the
> accessible members rather the public members (in public classes).
Would you have concrete suggestions for this use-case, i.e. a framework that is not part of a
module, but having a need to access public types from exported packages and get reflective access to
objects supertype's protected members?

This actually is an urgent need for my bridge. The BSF4ooRexx package comes with a wealth of samples
to show ooRexx programmers how easy it is to use Java as a huge external ooRexx class library. Some
of these samples in Java 9 now cause warnings, e.g. one example:

    ... cut ...
    WARNING: An illegal reflective access operation has occurred
    WARNING: Illegal reflective access by org.rexxla.bsf.engines.rexx.RexxAndJava
    (file:/C:/Program%20Files%20(x86)/BSF4ooRexx/bsf4ooRexx-v600-20180101-bin.jar)

    to method sun.java2d.SunGraphics2D.setRenderingHint(java.awt.RenderingHints$Key,java.lang.Object)

    WARNING: Please consider reporting this to the maintainers of
    org.rexxla.bsf.engines.rexx.RexxAndJava
    WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access
    operations
    WARNING: All illegal access operations will be denied in a future release
    ... cut ...

So all of a sudden the reflection does not work anymore. The reason being that the graphic "g"
context in javax.swing.JComponent's paintComponent (java.awt.Graphics g) is actually a
"sun.java2d.SunGraphics2D" object, that according to this Java 9 warning is not exported and will be
an error in Java 10. (I have assumed, that if I would use a reflection Method object from
javax.swing.JComponent (which is protected and can only be accessed by ooRexx, if a dynamically
created subclass of JComponent is created from which the work is done) for setRenderingHint() that
invoking the Method object with the Sun object would succeed.)

There are other use-cases where such warnings occur.

No user of the ooRexx-Java bridge knows anything of the new module system in Java 9, nor should she
have a need to know if these sample programs have worked flawlessly in the past. Therefore I am
seriously interested to find a solution that adheres to the Java 9 module system.

> BTW: On protected members then I assume they have never been accessible to the bridge, maybe the
> bridge is using setAccessible to suppress the access checks for those cases?
Yes.
(Have been hoping that that need would be forgone eventually, when that reflection area gets
reworked, updated for this protected member case, if the object to be worked on stems from a
subclass to allow exactly the same thing the Java compiler has allowed for, this time for an
interpreted language.)

>
>>
>> ---
>>
>> The current implementation seems to do the following: it checks whether a class is from an 
>> exported package, if not it creates an exception. If the class is exported it then checks whether
>> the reflected member is public, if not it creates an exception.
>>
>> What I would have expected is this: everything like the current implementation, but in the second
>> step, if the member is not public, check whether the object's class for which the reflection
>> takes place is a subclass of the class that is being checked and if so, allow protected members
>> to be accessed as well. Hence: in the example presented, the packages 'mtest1' and 'mtest3' are
>> exported, the class 'mtest3.Class03A' extends 'mtest2.Class02A' which extends 'mtest1.Class01A'.
>> Therefore the object of type 'mtest3.Class03A' is a subclass of 'mtest1.Class01A', hence as
>> 'mtest1' is exported all 'mtest1.Class01A' public *and* protected members should be accessible to
>> the object of the subtype 'mtest3.Class03A' via reflection in Java 9 as well.
> You should find that the protected members are accessible in the sub-class (mtest3.Class03A in
> this case). They won't be accessible to the bridge code of course (as least not without some kind
> of rights delegation as John mentioned).

Not with Java 9 javac, the following Java program:

    public class TestUse
    {
        public static void main (String args[]) {
            mtest3.Class03A o=new mtest3.Class03A();
            System.out.println("o: "+o+", myClassName: "+o.myClassName);
        }
    }

yields the error message:

    F:\work\svn\bsf4oorexx\trunk\bsf4oorexx.dev\testUnits\bsf4rexx\java9modules>java  -cp
    ".;F:\work\svn\bsf4oorexx\trunk;.;C:\Program Files
    (x86)\BSF4ooRexx\bsf4ooRexx-v600-20180101-bin.jar;C:\Program Files
    (x86)\BSF4ooRexx\jni4net.j-0.8.8.0.jar;C:\Program Files (x86)\BSF4ooRexx\oorexx.net.jar;."
    --module-path out --add-modules mod_A,mod_B,mod_C TestUse
    Exception in thread "main" java.lang.IllegalAccessError: tried to access field
    mtest1.Class01A.myClassName from class TestUse
            at TestUse.main(TestUse.java:5)

Note: the TestUse class will be part of the unnamed module.

---

Ad "rights delegation mechanism": would that really allow the bridge from the unnamed module to do
what is needed and therefore sought, ie. accessing protected members in exported superclasses? If
so, how? Would you have any links for further reading?

If you could tell me that I misunderstood the access rules of the java.lang.invoke package and that
it was possible to use it and/or the jdk.dynalink package to overcome, I would definitely try to
apply that to solve this issue, as this is really very important for the users of the bridge for
whom it is simply impossible to solve this.

---

Alternatively: what is the problem that you see for the Java 9 module system, if access checking is
done with the extension of also allowing protected members to be used, if the object on which the
reflective access is to be carried out is indeed from a subclass of the defining class of the
java.lang.reflect object being supplied?

---rony