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

[Alex Buckley]

You've presented a new fact about A.

Yes, if A is going to dereference the object graph starting from the 
object created by C's code (presumably as an instance of one of C's 
classes) and passed to B's code, then B would need to read all the 
modules containing the classes of objects in the object graph.

And all those modules need to export the classes' packages to B as well.

And no, B's code cannot configure those other modules to export packages 
to it. This is a point of real tension between strong encapsulation and 
serialization libraries which I'm sure the Expert Group will take up.

Alex

On 12/3/2015 11:58 AM, Rafael Winterhalter wrote:
> 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
> <mailto: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>
>         <mailto: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> <mailto: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
>
>