`MethodHandles::privateLookupIn` has changed in this release that 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, `MODULE` mode is dropped. In other words, `MethodHandles::privateLookupIn` requires the caller lookup object that must be created by a member from the caller's module and not produced by cross-module teleporting.

      If a lookup object `L` is 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, the resulting lookup object 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 accessible to M1, then this lookup object `L` will fail to lookup members in D in this release but succeeds in previous release.




            • Assignee:
              mchung Mandy Chung
              mchung Mandy Chung
            • Votes:
              0 Vote for this issue
              1 Start watching this issue


              • Created: