As I understand it, this is not sufficient. 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? 2015-12-03 20:48 GMT+01:00 Alex Buckley <alex.buck...@oracle.com>: > "needs to find all modules potentially involved" ? Module B needs to > configure readability to solely the module containing the class that A's > code (well, the code-that-used-to-be-A-but-is-now-part-of-B) wishes to > access reflectively. Here it is: objFromC.getClass().getModule(). > > Alex > > On 12/3/2015 11:43 AM, Rafael Winterhalter wrote: > >> But then library B needs to find all modules potentially involved. With >> the classical example of a serialization library that traverses a full >> object graph, this would require B to do the same for anytime an object >> is handed to the shaded dependency. To me that appears impractical. >> >> Am 03.12.2015 8:37 nachm. schrieb "Alex Buckley" >> <alex.buck...@oracle.com <mailto:alex.buck...@oracle.com>>: >> >> Yes, A's reflective access to C's classes will fail, due to the >> action of B's author in grabbing and shading A. >> >> Module B is responsible for configuring its (B's) readability to the >> module containing C's classes (be that a named module if C has been >> modularized, or the unnamed module if C is still a JAR on the >> classpath). >> >> Module B can achieve this with a single call to >> j.l.r.Module::addReads. >> >> Alex >> >> On 12/3/2015 11:19 AM, Rafael Winterhalter wrote: >> >> Sorry, I realize that I was not precise. >> >> Assuming that pre-module library A is shaded by modularized >> library B. User >> code C is then using library B. Internally, library B passes >> objects to >> library A that is using reflection on C without being aware of >> the module >> boundary. Would this now fail as library A is now part of B's >> module? >> Am 03.12.2015 8:10 nachm. schrieb "Alan Bateman" >> <alan.bate...@oracle.com <mailto:alan.bate...@oracle.com>>: >> >> >> On 03/12/2015 18:30, Rafael Winterhalter wrote: >> >> As a follow-up question. What if I need to import a >> library into my >> namespace and therewith module? ("shaded dependencies") >> This is a quite >> common practice to avoid version conflicts. >> >> Would for example the reflection semantics for these >> classes change? Or >> would the byte code level serve as a fallback? (But then >> the mentioned >> "modularity for pre-9 libraries" would not work.) >> >> Can you expand the example a bit? I assume the uber JAR >> has the >> >> dependences (in renamed packages) but those packages are not >> exported. In >> that case then none of the types in the shaded dependences >> will be >> accessible outside of the module. Within the module, which >> includes the >> shaded dependences, then all public types are available to >> code in the >> module, doesn't matter if the reference is static or core >> reflection. >> >> -Alan >> >>
