[foreign] RFR 8222337: Binder use of MethodHandles.publicLookup is bogus

[Maurizio Cimadamore]

Hi,
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 
options:

* 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'.

Webrev:
http://cr.openjdk.java.net/~mcimadamore/panama/8222337/

Cheers
Maurizio