On 21/10/2016 10:08, Jochen Theodorou wrote:
:
And another example...
Module A:
package a
class X {
protected void foo(){}
}
unnamed Module:
package u
class Y extends X{
public void bar(){ foo() }
}
How am I supposed to realize the call to foo using a runtime based on
classic reflection? I have only one chance, and that is to have the
actual Method.invokeMethod call at the callsite of foo(). If I do not
do that, I have other frames in between and then @CallerSensitive will
see the "wrong" intermediate frames and assume the call is not made
from a class that actually has access. So I have about 5 frames of my
runtime that will be in the way to realize this call.
For this scenario, assuming a.X is public and module A exports a, then
code in u.Y should be able to invoke foo with an invokevirtual or core
reflection. If you have intermediate frames and the immediate caller of
foo is not in package a or a subtype of X then the access check will
fail, we don't need modules in the picture to demonstrate that. If I
read your mails correctly then you've been using setAccessible to
suppress the access check so that the Method::invoke doesn't fail. This
can't work with "strong" modules (mostly JDK modules at this time), it
will continue to work with modules that choose to open/expose packages
for this type of access.
I'm not sure what to say except that mlvm-dev is usually good for
advice, in this case alternatives using method handles. You may be able
to get advice on the method reselection issue there. I see Andrew Dinn
has brought up agents and they do have the capability to update module A
to open package a to the module with the caller frame. Injecting code
into A to coerce it to open the package to your module will do the same,
as would injecting code into A that gives you a Lookup object with the
lookup modes you need.
well, we changed it exactly because the bulk variant is faster. It
might be not much difference. Bunt if you have to create a few
thousand meta classes, it makes a difference. And as stated above, a
@CS variant will get us nowhere. I don't know why all the JDK people
seem to think that @CS saves the world...
Core reflection has always been @CS, I don't see how this could be
changed now. In other areas then we do need to reduce the number of @CS
method over time. In previous mails then you've brought up
java.sql.DriverManager, that is one example where there is effort to try
to address this (very difficult to change it due to compatibility
concerns and could take a number of major releases to eventually remove
it completely).
-Alan
