Some frameworks need the ability to inject helper code into partially cooperative but inaccessible classes, or at least associate that helper code, as if the class had somehow "adopted" it. Crucially, the helper code often needs access to types or members of the cooperative class, when those types or members are not generally accessible: The may be private, package-scoped, or non-exported public.

If a partially cooperative class could be induced to create a MethodHandles.Lookup object for itself, and hand that object (as a capability) to a framework it trusts, then the framework could create the associated code with the necessary access privileges. (The privileges would be exposed via method handles, not native or reflected name resolution.)

This bug does not attempt to deal with full code injection as provided by some AOP systems (e.g., framework injection of interposed precondition checks on methods). It only covers the delegation of access privileges to third party frameworks.

An API for this needs to be easy to review for correctness. It should also provide a "right-sized" limited access, just enough for the use case. It should not be a "super user" privilege, nor should it allow further elevation.

The API definition needs to respect decisions made during application consolidation to seal modules (in some useful sense), even against frameworks. Again, it needs to allow (in some fashion) application consolidators the ability to allow frameworks to receive access delegation even after a module is (in some sense) sealed.

Straw man design #1: Unsafe.privateLookupIn(Class), Unsafe.packageLookupIn(Class), Unsafe.moduleLookupIn(Module), Unsafe.annotatedLookup(Annotation).

Straw man design #2: MethodHandles.doWithPrivateLookupIn(Class, Function<Lookup,T>). (Cf. doPrivileged.) Disables the lookup object at the end of the call.

Additional restrictions are (in theory) possible on the delegated Lookup object:
- could only work during a critical section (doWith)
- could refuse "teleportation" (Lookup.in)
- could work only for one Lookup operation
- could work only for a pre-specified query
- could be confined to a single thread (not shareable)
- could be confined to members with a pre-specified annotation
- could be used only from code that possesses some particular annotation (with a JVM check, cf. @CallerSensitive)

Such restrictions would have value mainly because they would make it easier to reason statically about the sensitive code that performing the delegated access. Such code is inherently difficult to reason about, yet must be vetted with extreme care.