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.buck...@oracle.com
<mailto:alex.buck...@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.buck...@oracle.com <mailto:alex.buck...@oracle.com>
<mailto:alex.buck...@oracle.com <mailto:alex.buck...@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.bate...@oracle.com
<mailto:alan.bate...@oracle.com> <mailto:alan.bate...@oracle.com
<mailto:alan.bate...@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
