JDK-8228624 : Release Note: MethodHandles::privateLookupIn Requires PRIVATE Lookup Mode
  • Type: Sub-task
  • Component: core-libs
  • Sub-Component: java.lang.invoke
  • Affected Version: 14
  • Priority: P4
  • Status: Closed
  • Resolution: Delivered
  • Submitted: 2019-07-25
  • Updated: 2021-05-14
  • Resolved: 2020-08-04
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 14
14Resolved
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.