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

[Rafael Winterhalter]

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