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.
