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

[Rafael Winterhalter]

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