MethodHandles.Lookup and modules

[Alan Bateman]

On 09/12/2015 14:54, stanislav lukyanov wrote:
>
> 1) Lookup.in() javadoc says
> "If the lookup for this Lookup is in a named module, and the new 
> lookup class is in a different
> module M, then no members, not even public members in M's exported 
> packages, will be accessible"
> However, it seems to be possible to have PUBLIC access after
> lookupInA.in(ClassInB.class)
> without breaking "no more access capabilities than the original" rule.
>
> Are such transitions intentionally forbidden?
Yes, this is intention as the lookup class and mode bits would otherwise 
not be sufficient when you teleport through a sequence of lookup 
classes. It might be clearer if you extend the example to 
in(B.class).in(C.class).in(D.class) where B, C and D are in different 
named modules and work out the intersection.

>
>
> 2) Lookup.in() javadoc says
> "If the lookup class for this Lookup is not in a named module, and the 
> new lookup class is
> in a named module M, then no members in M's non-exported packages will 
> be accessible"
>
> Spec says nothing about M's 'requires' and 'exports to M'.
> In current implementation, modules required by M are still accessible
> and packages exported to M (with 'exports to')  are not accessible.
>
> It seems right that packages exported to M are not accessible.
> Should it be specified in the javadoc, or is it implied due to 
> definitions somewhere else?
It is implied because the javadoc provides the guarantee that the 
resulting Lookup has no more access than the original. In this case 
there are packages exported by M's friends to M that are not accessible 
to code in unnamed modules. However, I think you are right that this 
could be make clearer in the javadoc. I'm sure that once the design 
settles down that we'll do several passes over the javadoc.

> :
>
> However, this creates some uncertainty.
> Suppose we have A requires B. From user's point resulting lookup of
> publicLookup().in(ClassInA.class)
> may or may not have access to the module B - it depends on module A's 
> 'requires' which user doesn't know about.
>
> It may come to the following situation. Code
> publicLookup().in(BlassInA.class).findStatic(ClassInB.class, "m", 
> ...).invoke()
> works with version of A that have 'requires B'.
> In the next version, A removes 'requires B' which should not
> have any impact on A's users, but the code above stops working.
Sure, the other thing is that readability graph can mutate at run-time 
so that `A` reads additional modules.


>
>
> 3) publicLookup() seems to allow work around the module access control.
> publicLookup() is available for any module and has access to any 
> module's exported packages.
> So, if we have modules A and B that do not require each other, we can 
> still access B from A:
> // code in A
> publicLookup().in(ClassInB.class)
>
> Is it OK to be able to do such tricks?

The publicLookup can only be used to access types that are are public 
and in packages that are exported unconditionally. It can't be used to 
break encapsulation, either directly or by teleporting and using a 
lookup class in another module.

Also `A` can call addReads to read any other module so this allows it to 
access any public type in any package exported by other modules if it 
really wants. This means that there is nothing that the publicLookup can 
be used to access that `A` can't access anyway.

-Alan