JEP-181: Nest-based Access Control is integrated into JDK 11 b20 (original) (raw)

David Holmes david.holmes at oracle.com
Tue Jul 10 01:21:20 UTC 2018

JEP-181 Nest-based Access Control:

https://bugs.openjdk.java.net/browse/JDK-8046171

has been integrated into JDK 11 and is now available in the b20 EA build. The Release Note for "nestmates" (as this work is informally known) can be seen here:

https://bugs.openjdk.java.net/browse/JDK-8203901

For those interested in technical details the review threads can be seen here:

http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-May/032228.html http://mail.openjdk.java.net/pipermail/serviceability-dev/2018-May/023718.html http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-May/053144.html http://mail.openjdk.java.net/pipermail/compiler-dev/2018-May/011885.html

This work has little direct impact on the Java programmer - there are no language changes, and importantly, no access rule changes. What nestmates basically does is to make the JVM aware of "nests" and to enforce nest-based access control, so that Java compilers, like javac, can simply identify which classes and interfaces form a nest, and then generate direct method invocations or field accesses between nest members, and have the JVM do the access checking. This avoids the need to generate access bridges.

The main impact of nestmates is on tools that process class files, as new class file attributes have been added to record nest membership. Tools may need to be aware of this so that the new attributes are either skipped or processed appropriately. Some tools have already initiated nestmate support, for example ASM 6.2 has nestmate support as an experimental feature, with full support coming with ASM 7, once JDK 11 is released.

The nestmates work made some additional changes in the JVMS to simplify use of the different invocation bytecodes. In particular, invokespecial was previously required to be used for invoking private interface methods, but now invokeinterface may also be used (and must be used where the rules for using invokespecial do not hold). The javac compiler was updated to issue invokeinterface for all private interface method invocations, and to use invokevirtual for all private class method invocations. Previously javac would issue invokespecial for private method calls within a class, though invokevirtual works just as well, but now invokevirtual is preferred for simplicity and uniformity.

Regards, David

More information about the jdk-dev mailing list