is ClassLoader.loadClass() supposed to work on module-info classes?
alex.buckley at oracle.com
Thu Dec 3 22:36:52 UTC 2015
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.
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.Bateman at 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
>>> 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
>>> 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.
More information about the jigsaw-dev