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. /Kasper [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2018-October/014012.html [2] https://bugs.openjdk.java.net/browse/JDK-8213251 [3] https://gist.github.com/kaspernielsen/540aacaf0581e7be80b0ebe3348f4a24 On Mon, 1 Jul 2019 at 20:51, Mandy Chung <mandy.ch...@oracle.com> 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: https://bugs.openjdk.java.net/browse/JDK-8226916 > > webrev: > http://cr.openjdk.java.net/~mchung/jdk14/8173978/webrev.00 > > javadoc: > http://cr.openjdk.java.net/~mchung/jdk14/8173978/javadoc/java.base/java/lang/invoke/MethodHandles.Lookup.html > > http://cr.openjdk.java.net/~mchung/jdk14/8173978/javadoc/java.base/java/lang/invoke/MethodHandles.html#privateLookupIn(java.lang.Class,java.lang.invoke.MethodHandles.Lookup) > > 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
