[foreign] RFR 8222337: Binder use of MethodHandles.publicLookup is bogus
maurizio.cimadamore at oracle.com
Thu Apr 11 13:10:27 UTC 2019
since JDK 9, the behavior of MethodHandles::lookup vs
MethodHandles::publicLookup has changed slightly:
1) MethodHandles::lookup() does access check using full module graph
(e.g. including checks whether the module of the lookup class 'reads'
the module in which the accessed member is defined)
2) MethodHandles::publicLookup() does a more relaxed check - as long as
the accessed member is in some public type defined in an
_unconditionally_ exported package, access is granted. Module reads are
_not_ taken into account.
The lack of checks for module reads is what made use of
MethodHandle::publicLookup appealing for Panama: after all, the binder
lives in java.base and java.base does NOT read user-defined modules.
That said, publicLookup() has issues - in that it only works if the
package in which the member is defined is unconditionally exported. So,
any modular use of the binder will quickly run into issues.
The best option is to use a regular lookup, rather than a public one.
But then we have problem with module reads; to address these we have two
* add the required module reads dynamically
* call setAccessible on the reflective member we want to obtain a MH for
Given the simplicity of the latter approach, I decided to go down that
route. I also added a test which checks that we can create callbacks for
interfaces which sit at various level of package 'exported-ness'.
More information about the panama-dev