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

[Alex Buckley]

"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.buckley at oracle.com <mailto:alex.buckley at 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.Bateman at oracle.com <mailto:Alan.Bateman at 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
>