`MethodHandles::privateLookupIn` has been changed. In this release, the caller `Lookup` must have both `PRIVATE` and `MODULE` access because an application intending to share intra-module access using `MODULE` alone will inadvertently also share deep reflection to its own module.   In addition, if a `Lookup` object is created by `Lookup::in` or `MethodHandles::privateLookupIn` teleporting from one module to another module, the `MODULE` mode is dropped.  In other words, `MethodHandles::privateLookupIn` requires that the caller lookup object must be created by a member from the caller's module and not be produced by cross-module teleporting.

For example, a lookup object `L` created by calling `MethodHandles.privateLookupIn(C.class, caller)` (where C is a class in module M1, and the caller's lookup class is in module M0) can access public members of public class D in module M2 if:
 
- M0 and M1 read M2, and 
- D is in a package exported from M2 to at least both M0 and M1.   

If D in M2 is accessible to M0 but not to M1, lookup object `L` will fail to lookup members in D in this release, but would have succeeded in previous releases.