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

Rafael Winterhalter rafael.wth at
Thu Dec 3 20:36:17 UTC 2015

Given that B, a public library that is not aware of C (and does therefore
not read C) wants to access that module's class via reflection, it needs to
add a read edge to C as discussed.

If an object of C references an object of D that is returned by reflection
on objects of C, the same holds for this other module.

If it is not B but the shaded A that uses reflection, then B needs to add C
and D before passing the object to A.

Is that incorrect?
Am 03.12.2015 9:24 nachm. schrieb "Alan Bateman" <Alan.Bateman at>:

> On 03/12/2015 19:43, 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.
>> I think I've lost you here or maybe the example has teleported.
> As I understand the example then code in A (which is in module B) is
> trying to use core reflection to access some type in consumer module C.
> Assuming the C type is public and in a packaged exported by C to B then the
> code in A should be able to access it, it just needs to use
> jlr.Module::addReads as Alex said. It may be that B already reads C, in
> which case this addReads will be a noop. So no walking objects graph or
> anything complicated in this example.
> -Alan.

More information about the jigsaw-dev mailing list