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
