is ClassLoader.loadClass() supposed to work on module-info classes?

[Alex Buckley]

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