On 22.01.2018 12:18, 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.
Yes, you are right! There need to be a public member that is capable of
accessing the protected ones
in this case.
Obviously I have used too many variants and mixed up the use cases, really
sorry for the noise! :(
---rony
