Similar scenario exists in nashorn world. We use Layers API to create single-dynamic-Module Layers and Module.addExport for qualified exports across Layers.
* Nashorn (qualified) exports of it's runtime code to dynamic module with Module.addExport * addExports managed by generated code's static initializer of the "dynamic module" (again to have qualified export from dynamic module to nashorn runtime) http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/39dececd7338 -Sundar On 6/1/2016 3:33 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.
