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

[Jochen Theodorou]

On 11.07.2016 09:46, Alan Bateman wrote:
> On 10/07/2016 11:04, Jochen Theodorou wrote:
[...]
>> 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.

probably same package, most likely something like 
className+separator+methodName, so I guess it is in M1. It surely would 
be interesting to look at both cases, but I am fine with just looking at 
the M1 case for now

> 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).

Can the MyReflection module generate code for the M1 module at runtime? 
It sounds strange, that I can change a module at runtime, since that 
could bypass the guarantees I gave at compile time. I certainly can 
create a class with the same package, but does this mean it will be 
automatically in M1, if the generation is done at runtime? I know I can 
do the generation in the unnamed module with the same package, but then 
it is not in M1. So I am missing some information here, or I have some 
wrong information.

> 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.

(b) M1Accessor would be a runtime generated module, created by 
MyReflection. Any reads needed for M1Accessor have to be added by 
MyReflection based code.
(c) I would have thought that this fails if M1Accessor is in the unnamed 
module.

Therefore, I guess M1Accessor has to be a named module created at runtime?

> 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).

sure

bye Jochen