MethodHandles.Lookup and modules

[Alan Bateman]

John,

Thanks for jumping in on this and the guidance. Comments inline.


On 10/12/2015 23:08, John Rose wrote:
>
> This stuff makes my head hurt, but I'm fine with any semantics that 
> preserves the following:
>
> 1. full power: MethodHandles.lookup() has the same privileges as 
> (non-constructor) bytecode in the caller class
Preserved, no changes.

>
> 2. downward monotonic
> 2a. L.in(A) never has more privileges than L (for all L, A)
> 2b. L.in(A) never has more privileges than a full power lookup on A 
> (for all L, A)
> 2c. as a corollary, a chain L.in(A).in(B).in(C)… has no more 
> privileges than L or any lookups in A, B, C, …
Preserved with the exception of A, B and C in the same named module M 
and where the set modules that M reads increases (say where code in M 
reads additional modules).

>
> 3. graceful degradation:  L.in(A) loses only privileges broken by the 
> distance between LC=L.lookupClass and A
> 3a. if A==LC no privileges are lost; the identical L can be the result
> 3b. if A and LC are nestmates, only protected privileges may be lost 
> (dynamic emulation of JLS nestmate access)
> 3c. if A and LC are in the same package, only private privileges may 
> be lost
> 3d. if A and LC are in the same module, only package privileges may be 
> lost
Preserved but perhaps with the (initially surprising) consequence that 
all access is lost when m(LC) is a named module and m(A) is a different 
module. This arises because the two modules may read very different sets 
of modules, the intersection cannot be expressed via a lookup class + modes.

>
> 4. downward convergence (to publicLookup or empty privileges)
> 4a. if A is inaccessible to LC=L.lookupClass, L.in(A) has no 
> privileges (less than publicLookup)
> 4b. if A is accessible to LC and L has non-empty privileges, L.in(A) 
> is no less privileged than publicLookup
> 4c. for any L with non-empty privileges, there is a sequence of types 
> A,B where L.in(A).in(B) is equivalent to publicLookup
Downward convergence to zero access/empty privileges.

No downward convergence to publicLookup because 
m(publicLookup.lookupClass) must read all modules, thus a superset of 
the modules that named modules will read. I should say of course that 
the publicLookup can only be used to create method handles to public 
members in packages that are exported unconditionally.  So nothing that 
code in a named module couldn't otherwise access when it increases 
readability.


>
> 5. publicLookup has a reasonable minimal set of globally acceptable 
> privileges
> 5a. this set of privileges is singular, and does not depend on the 
> lookupClass
> 5b. the only possible results of publicLookup.in(A) are no change, and 
> falling to empty privileges
publicLookup is minimally trusted and so can only create method handles 
where the target type is public and exported (unconditionally).

For 5b then publicLookup.in(A) may result in no change or degrade but 
not to empty privileges in one hop. The "no change" case is where A is 
in an unnamed module (think class path). The "degrade" case is where A 
is a named module and so the resulting lookup can only be used to access 
the public types that are exported unconditionally by modules that m(A) 
reads.


>
> Access can only be measured against the current state of the module graph,
> which means that certain results can vary over time, in a consistent way
> across the whole system.
Yes, consistent with bytecode and also the access checks in core reflection.

>
> The above are my preferences; I can imaging tweaking some of those things
> in order to make the API fit more gracefully into modules.  I rely on 
> Alan & co.
> to figure that out!
and we rely on you to ensure that what we do make sense. I hope this 
does not constitute a circular dependency :-)


> :
>
>
> (BTW, see https://bugs.openjdk.java.net/browse/JDK-8145070 )
The defining loader of publicLookup.lookupClass() is no longer null and 
looks like Nashorn trips up on the permission check in 
Class::getClassLoader.



>
>
> I agree with this.  Lookups are primarily about emulating bytecode 
> behavior (not reflection behavior), and providing a framework for safe 
> and sane delegation.
Adding edges to the readability graph impacts all access checks 
consistently and I think in a safe way.



> :
>
> Does publicLookup.in(A) create a new set of privileges depending on A?
>
> I think that is the current design; maybe it's best, but it's a little 
> odd.
> If there really is a uniquely minimal set of public privileges,
> then that should be publicLookup, and PL.in(A) should not affect
> that minimal set.  That's the intention of saying the LC of PL is
> mere convention.
As publicLookup is no longer the minimal set of privileges then 
publicLookup.in(A) will impact reduce access for the case that m(A) is a 
named module. Stanislav makes a good point about the javadoc as a named 
module may not read all modules and so publicLookup needs to be in an 
unnamed module for now.


>
> We can modify axiom #5 to say:  PL accesses a unique family of
> privileges sets, indexed by the LC of each PL.  This family is
> minimal in the sense that, for any PL in the family, and any
> lesser privileged L, L is either another member of the PL family,
> or has empty privileges.
>
> In this case, the LC of a PL provides a scoped or restricted
> view of "really public" names, all of which are non-problematic
> to view from any point in the system.  The fact that you have
> to dial in a special LC to get to one of those names is merely
> a formality.  No abstraction can ever be broken via a PL,
> even if the various PLs have slightly different capabilities.
>
> (N.B.  Because of 4a, PL.in(A) can go empty, if PL.LC cannot
> access A.)
>
I hope the adjustments that we have are reasonable. We start with a 
singleton PL that can produce method handles to public members of 
exported packages. It can then be restricted, with PL.in(A), to just the 
public types exported unconditionally by A or the modules that A reads.

We have looked of taking snapshots and persisting intersections but it 
diverges from bytecode behavior which I think rules it out.

-Alan