Introduce nests, an access-control context that aligns with the existing notion of nested types in the Java programming language ([JEP-181: Nest-based access control](http://openjdk.java.net/jeps/181)).

In Java SE 11, the Java Virtual Machine supports the arrangement of classes and interfaces into a new access control context, called a _nest_. Nests allow classes and interfaces that are logically part of the same code entity, but which are compiled to distinct `class` files, to access each other's `private` members without the need for compilers to insert accessibility-broadening bridge methods. Nests are a low-level mechanism of the Java SE Platform; there are no changes to the access control rules of the Java programming language. The `javac` compiler has been updated to use nests when compiling nested classes and interfaces in Java source code, by generating new `class` files attributes that place a top-level class (or interface) and all its nested classes and interfaces in the same nest. The Java Virtual Machine has been updated to use these attributes when checking the accessibility of a `private` constructor, method, or field, including via core reflection and the `java.lang.invoke.MethodHandles.Lookup` API. Membership in a nest is exposed through the new `getNestHost` and `getNestMembers` methods of `java.lang.Class`.

As nest membership is recorded in the `class` file of the top-level class or interface (the _nest host_), that `class` file must be present at run time to allow the access control checks to be performed. This is not normally a concern as the top-level class or interface is typically used directly. In some code where a top-level class or interface acts only as a holder for nested classes or interfaces, and is otherwise unused, packaging tools may have elided that `class` file from the distribution of a library or application. With nest-based access control, it is no longer possible to elide the top-level class or interface if any of the nested classes or interfaces require access to each other's `private` members — a `NoClassDefFoundError` or `ClassNotFoundException` will be thrown.