Review Request: JDK-8173978: should allow teleporting from a lookup class in a named module without dropping all access

Kasper Nielsen kasperni at
Tue Jul 2 15:35:45 UTC 2019

Hi Mandy,

Are there any plans to make functionality from VerifyAccess public in any way?
Changes to the access model like these are extremely frustrating because
the access check mechanisms in VerifyAccess are not available outside of
the JDK.

I've posted about this before [1][2], But if you are a library
developer there are basically
no way to cache a MethodHandle and allow it to be used against
multiple different
Lookup objects because the access checks are so complicated.

Another really useful addition would be a LookupValue class (similar
to ClassValue) which
would allow you to cache access check information for a given lookup
object. Right now,
I'm using a cache of ClassValue<ConcurrentHashMap<Integer, T>>
with lookupClass and allowedModes as parameters [3]. This will
obviously break with
these changes.

A simple use case is implement a simple serialization library with the
following signature
  String serializeToString(Class<?> clazz, MethodHandles.Lookup lookup).
Trying to implement something like this that is both performant,
secure and classloader
friendly is really difficult. Creating varhandles/methodhandles for
every call to
'serializeToString ' is not performant for obvious reasons. So you
need to cache it in
some way, which is currently non-trivial.



On Mon, 1 Jul 2019 at 20:51, Mandy Chung <mandy.chung at> wrote:
> This is an enhancement to |`Lookup::in`| and
> |`MethodHandles::privateLookupIn`| API
> for cross module teleporting.  A `Lookup` object will record the previous
> lookup class from which this |Lookup| object was teleported such that
> the access check will use both the previous lookup class and the current
> |lookup| context (current lookup class and allowed modes) to determine if
> a type is accessible to this `Lookup` object or not.
> In a nutshell, `T` in M2 is accessible to a `Lookup` object on `C`
> (lookup class in M1) and `PLC` (previous lookup class in M0) if and only if
> 1. both M0 and M1 can read M2
> 2. T is in a package that is exported from M2 at least to both M0 and M1
> Detailed specification is in Lookup class spec and `accessClass` javadoc.
> The relevant spec about cross-module teleporting is in the Lookup class
> spec and `Lookup::in` and `MethodHandles::privateLookupIn`.
> CSR:
> webrev:
> javadoc:
> I have yet to generate the spec diff. The tool is currently broken
> due to javadoc change.  I'll try to workaround it and post the
> spec diff soon.
> thanks
> Mandy

More information about the core-libs-dev mailing list