Gradle not working on Jigsaw

Alan Bateman Alan.Bateman at oracle.com
Sat Oct 22 10:57:14 UTC 2016


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


More information about the jigsaw-dev mailing list