MethodHandles.Lookup and modules

[stanislav lukyanov]

Hi Alan and Jigsaw Team,

I have questions regarding Jigsaw-related updates in MethodHandles.Lookup.

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?


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?

I have some doubts about M's 'requires' (non-public).
Technically, allowing access to non-publicly required modules for PUBLIC 
lookup looks correct because
- the only way to have only PUBLIC access to lookup module is to 
teleport to a named module from an unnamed
- unnamed module has access to all named modules anyway
so the requirement of "having no more access" after Lookup.in() is 
fulfilled.
(BTW, if Lookup.in() were allowed then the reasoning would break. But it 
depends on the answer on (1))

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.


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?

Thanks,
Stas