A lot of questions around the configuration of a reflective style library

[Alan Bateman]

On 10/07/2016 11:04, Jochen Theodorou wrote:

> Hi,
>
> since Alan suggested to make a new thread for this (coming from 
> "Feedback on proposal for #ReflectiveAccessToNonExportedTypes"), I 
> will do just this.
Thanks for starting a new thread.

>
> Let me rephrase the scenario from there a bit:
> I am trying to figure out the configuration and implications of the 
> configuration and what is different to from before using modules. Let 
> us for simplicity assume we talk only about classes with public 
> modifier and all modules are loaded with the same class loader.
>
> We have a reflective library as module MyReflection, which uses 
> classes generated at runtime to realize access similar to reflection. 
> Let us also ignore where the information for classes and signatures 
> come from. Then we have a Module M1, which has hidden API and wants to 
> use MyReflection to access its own hidden API. The question here is 
> about how to make the configuration and maybe what has to be done with 
> regards to layers to enable this or if that is not possible. 
Can you say a bit more about the "classes generated at runtime"? Are 
they generated into one of M1's existing packages? My reason for these 
questions is to establish if there are two or three modules in the picture.

If the generated code is in M1 then I think the picture you describe is:

M1 --(a)--> MyReflection --(b)--> M1 --(c)--> M1.

(a) M1 calls into the MyReflection module, we'll assume M1 reads 
MyReflection and further assume that MyReflection exports its API.

(b) MyReflection invokes the generated code in M1. I can't tell from the 
picture how this is done but we'll assume MyReflection reads M1 and that 
the generated code in M1 is in a package that is exported to MyReflection.

(c) The generated code in M1 calls the so-called "hidden API" in M1. 
Readability and exports aren't interesting here as everything is in the 
same module. We'll just assume the hidden API is public (the invoke* 
would otherwise fail of course, assuming the generated code and hidden 
API are in different packages).


Now suppose the generated code is generated into a different module. I 
think the picture is then:

M1 --(a)--> MyReflection --(b)--> M1Accessor --(c)--> M1.

M1Accessor could be an named module, it could be an unnamed module.

(a) Same as above.

(b) MyReflection invokes the generated code in M1Accessor. As above, you 
haven't said how this is done but we'll assume that MyReflection reads 
M1Accessor. If M1Accessor is a named module then we'll assume that the 
package with the generated code is exported to MyReflection (if 
M1Accessor is an unnamed module then it exports everything).

(c) Here we have code in M1Accessor trying to invoke the so-called 
hidden API in M1. For this to work then M1Accessor needs to read M1 and 
M1 needs to export the package with the hidden API to M1Accessor.

There is more that can be said as to how all the above could be arrange, 
also lots to say about parts 2 and 3. Before going there then maybe we 
could reduce the scope down to one scenario as I suspect it might be 
confusing to have a matrix of scenarios in the discussion (esp. when we 
get to the other parts).

-Alan.