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
