question on exports to

[Peter Levart]

Hi,


On 06/01/2016 12:03 PM, Alan Bateman wrote:
> On 01/06/2016 09:34, Jochen Theodorou wrote:
>> :
>>
>> This now looks to me like this... GeneralInvoker will have to call 
>> generalInvokerModule.addReads(myOtherLibModule), to enable to inspect 
>> the classes from that library. It will then spawn a layer with a 
>> named module, which contains the invocation code. This layerModule 
>> will contain code to call layerModule.addReads(myOtherLibModule), so 
>> it can access the classes in MyOtherLib if they are exported.... and 
>> since that is not yet the case, I will have to cause MyOtherLib to 
>> call myOtherLib.addExports("my.lib", layerModule).
>>
>> Which still means I cannot replace reflection completely, since it 
>> does not have to cause MyOtherLib to call 
>> myOtherLib.addExports("my.lib", layerModule). Or it means I still 
>> lack understanding - which would not surprise me at all.
> I don't wish to cause confusion in this thread but I think what you 
> are looking for is:
>
> 1. MyOtherLib declares`requires GeneralInvoker`.
>
> 2. GeneralInvoker resolves "MyOtherLib" to create a configuration, 
> that configuration is then instantiated as a module layer. There will 
> be at least one module in that layer, maybe others if there are other 
> dependences. GeneralInvoker will use findModule to locate the module 
> named "MyOtherLib".
>
> 3. GeneralInvoker will use Module.addExports to export com.foo.gi to 
> the runtime module MyOtherLib (from the thread then I gather than 
> com.foo.gi is not exported, at least not unconditionally). This will 
> allow the code in my.lib.SomeClassOfTheLibrary to invoke the public 
> invoke method in com.foo.gi.TheInvoker.
>
> 4. The static initializer in my.lib.SomeClassOfTheLibrary will export 
> my.lib to GeneralInvoker using Module.addExports. Again, I'm assuming 
> that my.lib is not exported unconditionally. This one might be strange 
> and non obvious but arises because qualified export aren't supported 
> across layers. The "no forward reference" rule should be clear, it 
> would be a security hazard. The "no back reference" (mean qualified 
> exports to modules in parent layers) is a discussion point. It's 
> useful in some scenario (like this one), not useful with static 
> references because it would not make sense. This is a topic in itself 
> and I don't wish to complicate your cage fight by going into this here.
>
> With #4 then it allows GeneralInvoker to invoke the public methods in 
> MyOtherLib's my.lib package.
>
> As Alex noted, we need to write-up some of these "dynamic module" 
> scenarios so there are pictures and examples to point at.
>
> -Alan.

I also don't wish to cause further confusion, but I have a feeling that 
Jochen might have the following situation:

- MyOtherLib contains classes and code that is using these classes 
(invoking their methods), but it wishes to call those methods via an 
indirection through a GeneralInvoker that happens to live in another module
- MyOtherLib is also using classes (invoking methods) from other modules 
that it already has direct access to, but it wishes to call those 
methods via an indirection through a GeneralInvoker too

If that is true, then perhaps there is a simpler solution that doesn't 
require modifying the exports of any module.

Make your TheInvoker take another argument of type MethodHandles.Lookup:

public class TheInvoker{
     public static Object invoke(MethodHandles.Lookup lookup, Object 
receiver, String name, Object... args) throws Throwable {
         Method m = receiver.getClass().getDeclaredMethod(name, 
toClass(args));
         MethodHandle mh = lookup.unreflect(m).bindTo(receiver);
         return mh.invokeWithArguments(args);
     }
...
}


Then pass the appropriate lookup to it from where you call 
TheInvoker.invoke (from MyOtherLib):

TheInvoker.invoke(MethodHandles.lookup(), receiver, "methodName", 
arguments...);


Would that work?

Regards, Peter