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
