is ClassLoader.loadClass() supposed to work on module-info classes?
rafael.wth at gmail.com
Thu Dec 3 19:19:44 UTC 2015
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>:
> 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.
More information about the jigsaw-dev