When the author of B decided to shade A, it became B's responsibility to
configure the readability needed by A's reflective code.
"But B doesn't know anything about how A works. The shading was only to
use a different version of A than was observable on the modulepath."
OK, then shading A wasn't the right solution.
One possibility is to continue renaming A's classes, but to put them in
Aprime.jar on the modulepath. That would generate an automatic module
Aprime which B could require. The Aprime module reads everything, so its
reflective inspection of C's classes et al will work -- until an object
of some module-private class is reached.
So, I've solved your multiple-versions-of-A problem but I haven't solved
your encapsulation problem. Again, the tension between strong
encapsulation and serialization libraries is something I'm sure the
Expert Group will take up.
Alex
On 12/3/2015 12:43 PM, Rafael Winterhalter wrote:
The point is that A is shaded. It is compiled prior to Java 9 and not aware
of modules or Java 9 APIs. Therefore, it does not add read edges.
B only imports A to avoid conflicts with other versions of A where A
implicitly becomes a part of module B.
Am 03.12.2015 9:37 nachm. schrieb "Alan Bateman" <alan.bate...@oracle.com>:
On 03/12/2015 19:58, Rafael Winterhalter wrote:
:
Assuming A is a serialization library: If the object of C contains an
instance encapsulated by D, then B would need to make sure that it can
read
C and D before handing the instance to A. For this it would of course be
necessary to understand the inner workings of A. This is trivial for a
serialization library but in the general case this involves more effort
and
is difficult to accomplish without runtime errors.
Is that incorrect?
The B code doesn't need to do anything special here, it just passes
references to A code (in the same module). If the A code is doing
serialization then it's walking object graphs and might have to add some
transient read edges (via jlr.Module::addReads) as it goes. If the walk
leads to it trying to access types that aren't public or aren't in packages
exported to module B then it will get an IllegalAccessException, that is to
be expected. So I don't think there is any specific to shading or uber JARs
in this example.
-Alan.
