visibility, readability, accessibility and reflection

[Alan Bateman]

On 03/12/2015 17:12, Peter Levart wrote:
> :
>
> to compile and run, three things must hold (two for compile, three for 
> run):
>
> - module a must read module b
> - module b must export package q to at least module a

For completeness then the access check here will also check that D is 
public.

> - class q.D must be visible from class p.C meaning that they must 
> either be loaded by the same classloader or the classloader of p.C 
> must delegate to the classloader of q.D directly or indirectly
>
> Now lets exchange this constructor invocation expression with 
> equivalent reflection code in p.C::main:
>
>     Class<?> dClass = Class.forName("q.D");
>     dClass.newInstance();
>
> To run these two statements the same three things must hold. I would 
> expect that individual statements need the following:
>
>     Class.forName("q.D");
>
> - module a must read module b
There isn't an access check here so no checking that a reads b. There 
may of course be reasons why D might not be able to link to its 
supertype and other issues but I assume they aren't interesting here.

> - class q.D must be visible from class p.C meaning that they must 
> either be loaded by the same classloader or the classloader of p.C 
> must delegate to the classloader of q.D directly or indirectly
>
>     dClass.newInstance();
>
> - module b must export package q to at least module a
>
>
> But in fact, the newInstance invocation also needs:
>
> - module a must read module b
>
>
> So it seems that readability is checked both times. I would like to 
> know what is the reasoning behind that.
Class.forName doesn't do access checks so hopefully that makes things 
clearer.

One other thing to point out (or compare) is the new MH.Lookup.findClass 
(JEP 274). That emulates bytecode and so will check that the lookup 
class has access to the target class.

-Alan.