question on exports to
Alex Buckley
alex.buckley at oracle.com
Fri Jun 3 20:20:37 UTC 2016
On 6/3/2016 11:49 AM, Jochen Theodorou wrote:
> 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?
Yes.
> 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...
Why don't you believe it? The "Under The Hood" presentation shows that
layer creation makes the JVM aware of modules and their relationships.
Later, when the JVM resolves the descriptor of an invokevirtual
instruction, it checks that the current class (containing invokevirtual)
can access the class referenced in the descriptor, and this check takes
module membership, exports, and readability into account. Can the
current class's module read the target class's module, and does the
target class's module export the target class to (at least) the current
class's module?
There's a clear contrast between the two-way check performed by the JVM,
and the one-way check (exports only, readability "for free") performed
by Core Reflection.
Alex
> 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
More information about the jigsaw-dev
mailing list