visibility, readability, accessibility and reflection

[Peter Levart]

Hi Alan,

Thanks for answers...

On 12/03/2015 07:14 PM, Alan Bateman wrote:
> 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.

Ah, I see. When there's no "requires b" in module a, then b is not 
included in the configuration if I just do "java -m a/p.C", so that's 
the problem of visibility because of missing module. When I also 
"-addmods b", then Class.forName("q.D") works and I only get 
IllegalAccessException in .newInstance()

>
>> - 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.

Ok, very clear now. So: readability + exportability + class/member 
access modifiers == accessibility

It is now understandable why newInstance does all these checks.

>
> 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.

Right, MH.Lookup.findClass does accessibility checks upfront (at 
lookup-time), so MethodHandle.invoke() does not have to do them.

>
> -Alan.
>
>


But anyway. I'm trying to understand why a model where readability would 
be a requirement for visibility and so accessibility could be reduced 
to  exportability + class/member access modifiers is not a viable 
alternative? Would that require Class loading changes? It would not be 
possible to enforce this inside the class-loader, right?

Regards, Peter