MethodHandles.Lookup and modules

[Alex Buckley]

Hi John,

On 12/11/2015 12:38 PM, John Rose wrote:
> That's fine.  There are two main use cases for Lookup.in,
> neither of which require the tracking of long chains of L.in(A/B/C…).
>
> A. Agent with full-power lookup wants to invoke another agent with the lookup,
> but wants to limit access, because he doesn't fully trust the other agent.
> He does a single L.in(A) to a remote-enough type A, creating a non-full-power lookup.
> (Note:  Picking A is sometimes non-trivial.  This might be an API flaw.)
>
> B. Agent with full-power lookup wants to get access to private nestmate in A.
> He does a single L.in(A) where LC and A are in the same package member.
> This works around differences between access checks at JVM and JLS levels,
> just as the package-private accessor methods from javac do.  (Yuck!)

Focusing on case A, please consider the following design:

- PUBLIC lookup mode means:

   Any 'public' type of any package exported unconditionally by the 
package's module.

- QUALIFIED lookup mode means:

   Any 'public' type of any package exported in qualified fashion by the 
package's module to the lookup class's module.

- MODULE lookup mode means:

   Any 'public' type of any package in the lookup class's module.

(Sidebar: QUALIFIED is split from MODULE primarily to be explicit about 
access rights and secondarily to support more precise slicing of access 
rights in a future MethodHandles.Lookup API. Example: give me a lookup 
object to access the types in this module that offer a contract, i.e. 
are declared 'public' without regard to exported-ness. Example: give me 
a lookup object to access the types outside this module which are 
exported to it by its friends.)

- Start with an arbitrary class in an arbitrary module calling 
MethodHandles.Lookup.lookup() to get a "full power" lookup object L. L's 
lookup modes are PUBLIC + QUALIFIED + MODULE + PROTECTED + PACKAGE + 
PRIVATE.

- The arbitrary class obtains a Class object representing class A, then 
calls L.in(A):

   -- If A is in a different module than L's lookup class, then the 
resulting lookup object has lookup mode PUBLIC.

   -- If A is in the same module as L's lookup class, but a different 
package, then the resulting lookup object has lookup mode PUBLIC + 
QUALIFIED + MODULE + PROTECTED. (#include some stuff about actually 
accessing protected members outside A's package.)

   -- If A is in the same module as L's lookup class, and in the same 
package, but A is a different class than L's lookup class, then the 
resulting lookup object has lookup modes PUBLIC + QUALIFIED + MODULE + 
PROTECTED + PACKAGE.

   -- If A is the same class as L's lookup class, then the resulting 
lookup object has lookup modes PUBLIC + MODULE + PROTECTED + PACKAGE + 
PRIVATE.

- L.in(A) succeeds (returns a lookup object) regardless of whether its 
caller is in a module that reads A's module. Only when find* is called 
on a lookup object is there a check that the caller-of-find*'s module 
reads the module containing the lookup class embodied by the lookup 
object. It's easy for the caller-of-find* to pass the check by calling 
addReads(...) just before calling find*.

(Sidebar: Separately, the module containing the lookup class embodied by 
the lookup object had better have readability to other modules in order 
for find* to look up [ctors, methods, and fields of] classes in those 
other modules.)

> Should there be a way to build a lookup, for two modules M1/M2, which
> reads those names of M2 which M1 can read, except no internals
> of M1?  I wonder if such a thing would be useful?  Probably not.
>
> But it would be useful to have a lookup in a module M1 which can
> read the exports of *every* M2 that M1 can see, except no M1 internals.
> (This includes the unconditionally exported public names of M1.)
> This would be a Lookup with an LC in M1 and flags of PUBLIC only.

The difference between these two paragraphs is hard to discern. The 
first paragraph seems to fix M1 and M2 while the second paragraph fixes 
M1 and varies M2, but there's also a switch from "M1 can read" to "M1 
can see". Modules read modules, classes see classes, types access types. 
Can you restate?

Alex