visibility, readability, accessibility and reflection

[Alex Buckley]

On 12/3/2015 11:04 AM, Peter Levart wrote:
> On 12/03/2015 07:14 PM, Alan Bateman wrote:
>> On 03/12/2015 17:12, Peter Levart wrote:
>>> 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

Yes. This was explicitly stated in the first section of "Project Jigsaw: 
Under The Hood" -- accessibility is a two way street: module a reads 
module b, module b exports package q to at least module a.

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

This is an insightful question. Nothing is impossible, but it would 
require such deep changes to the JVM's class loading mechanism that it 
would make make the changes we've made to the JVM's access control 
mechanism look like child's play. (By "JVM", I mean the abstract JVM 
described in the JVM Spec, not any particular implementation such as 
HotSpot.)

Alex