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