On 01.06.2016 20:54, Peter Levart wrote:
[...]
Modules are part of language. Their exports / requires form a logical
layer of additional access checks to what we had before
(public/protected/package/private qualifiers on classes / members), but
are treated the same way during runtime. Together they form language
accessibility rules. There are exceptions, notably in reflection:
- Member.setAccessible(true) can not be used to circumvent lack of exports
- readability is implicitly provided for reflective access in general
so if I load a class that tries to use a class from a different module
and this class is not exported, the call will fail? I am talking here
about invokevirtual and the others. Sure, that is not supposed to
compile, but java is not the only things that generates bytecode. I
somehow fail to believe that for each invocation of a method the module
system is checked... or that such a class will fail verification...
which I also find difficult to believe. Your second point actually
suggests that there is some kind of post compilation check. Could you
please confirm if there is or not?
So the trick with Lookup shown above can be used to invoke a private or
package-private method via TheInvoker.invoke() like it was invoked directly:
class MyOtherClass {
private void myPrivateMethod() {
...
}
void someMethod() {
TheInvoker.invoke(MethodHandles.lookup(), this, "myPrivateMethod");
}
}
...as well as other public methods in modules that export packages to
the Lookup owner (the module of the class that obtains the Lookup object
via MethodHandles.lookup()).
that is actually good for our invokedynamic part.
bye Jochen
