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