JDK-8173978 : Lookup.in should allow teleporting from a lookup class in a named module without dropping all access
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.lang.invoke
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2017-02-06
  • Updated: 2019-11-04
  • Resolved: 2019-07-24
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
14 b08Fixed
Related Reports
Blocks :  
Blocks :  
CSR :  
Relates :  
Relates :  
Relates :  
Sub Tasks
JDK-8228624 :  
Lookup.in(Class<?>)  is currently specified to drop all access when teleporting from a lookup class in a named module to a lookup in another module. This is necessary to guarantee that the new lookup does not have more access than the old (because the new Lookup will do access checking with only the new lookup class).

[ The exception is publicLookup() where the lookup class is java.lang.Object (in java.base). The `in` method can be used to teleport to a lookup class in another module without loosing PUBLIC access. ]

This issue tracks re-examining this method with a view to having Lookup retain a reference to the old lookup class so that a "double access check" can be done to ensure that any method handles created are checked with both the old and new. All access would be be dropped with a second hop to avoid Lookup needing to remember more than one previous lookup class.

URL: https://hg.openjdk.java.net/jdk/jdk/rev/f557f260b787 User: mchung Date: 2019-07-24 23:47:49 +0000

Review thread: https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-July/061132.html