is ClassLoader.loadClass() supposed to work on module-info classes?
alex.buckley at oracle.com
Thu Dec 3 20:38:40 UTC 2015
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.
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:
> 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
> 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
> Module B can achieve this with a single call to
> 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
> 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
> 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
> This is a quite
> common practice to avoid version conflicts.
> Would for example the reflection semantics for
> 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
> 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
More information about the jigsaw-dev