Feedback on proposal for #ReflectiveAccessToNonExportedTypes

[Alan Bateman]

On 23/07/2016 01:32, Jason Greene wrote:

> :
> This was intended to mirror the same structure as the original example as well: A exports dynamic bar, and B exports bar, and also all modules are following a class loader per module paradigm.  I had a follow-up that corrected this, it should have read:
>
> "As an example perhaps the configuration file in [A] specifies a class name in [A]’s dependency, which is not visible to Victim. Or, perhaps A’s config leads to duplicate runtime actions being configured (since the file was really only indented for A, which also processes it)”
>
> It sounds from your description above that Victim’s classloader would not delegate to A’s class loader, so resources in A’s /bar would not be discoverable from Victim. Extending this scenario as you describe with B requires C.  I imagine that C’s contents would not be visible to Victim (unless it was defined B requires public C)?
>
I'm sure Mark will continue this thread but just to say that there is 
another open issue (#ResourceEncapsulation) on the JSR issues list that 
may be where you are going. If there is a resource in A (for use by A) 
then it may or may be not be located by code in other modules, that is 
part of the other discussion.

As regards the specific scenario, where a container arranges for a class 
loader per module, then Victim's class loader should not be delegating 
to A's loader, at least not for bar.* types and in the context of the 
updated semantics suggested earlier in the thread. This is of course not 
something that the module system really controls as you can map modules 
to class loaders and do delegation as you want (the module system places 
very few restrictions). The legacy getResource* methods are not 
specified to work with graphs of class loaders and not possible to say 
what the overridden implementations might do. So I think all we can 
really say here is that if the name of a type in C leaks to Victim then 
it may or may not be able to get a Class reference. It's no different to 
JDK 8 in this regard. It is of course possible that a C type gets leaked 
to Victim by other means. In that case then only the public types in C's 
exported packages will be accessible to Victim.

-Alan