question on exports to

[Sundararajan Athijegannathan]

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.