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

[Rafael Winterhalter]

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

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