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
