Details

    • Type: Sub-task
    • Status: Closed
    • Priority: P4
    • Resolution: Delivered
    • Affects Version/s: 14
    • Fix Version/s: 14
    • Component/s: core-libs

      Description

      `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.

        Attachments

          Activity

            People

            Assignee:
            mchung Mandy Chung
            Reporter:
            mchung Mandy Chung
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved: