JEP-181: Nest-based Access Control is integrated into JDK 11 b20

[David Holmes]

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