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

[Peter Levart]

On 01/22/2018 12:18 PM, Alan Bateman wrote:
> On 22/01/2018 09:58, Peter Levart wrote:
>> :
>>
>> The 2nd problem is not trivial as you want to access a protected 
>> member on behalf of some other sub-class of the member's declaring 
>> class which is not cooperating (voluntarily handing you an instance 
>> of its Lookup object). This currently requires the package containing 
>> the member's declaring class to be opened at least to you (the Rexx 
>> interpreter) and using the member.setAccessible(true) trick or 
>> MethodHandles.privateLookupIn(declaringClass) equivalent for method 
>> handles. Which is awkward because libraries packed as modules would 
>> normally not specify that in their module descriptors and system 
>> modules don't either. So you are left with either --add-opens command 
>> line switches or deploying a javaagent to the JVM and using it's API 
>> point java.lang.instrument.Instrumentation#redefineModule to add 
>> opens to modules that way. Both approaches are not elegant, but 
>> that's what is currently available, I think.
>>
> I suspect it may be just a misunderstanding. One of Rony's mails had 
> this example:
>
> o=.bsf~new("mtest3.Class03A")             -- create Java object, get 
> and assign proxy ooRexx object
> say "o:" o "o~myClassName:" o~myClassName -- get (static) field value 
> in "mtest1.Class01A", accessible via inheritance
>
> I read this as the Rexx script doing the equivalent of "new 
> mtest3.Class03A()", in which case should be no expectation that 
> protected members are accessible to the Rexx code.
>
> -Alan.

I was asking myself the same question, yes. If Rony wants to call 
protected methods on "behalf" of subclasses, then Rexx runtime has to 
have features to subclass existing Java classes.

@Rony: So why does Rexx script want to call protected members? Is that 
because Rexx can extend existing Java classes?

Regards, Peter