Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8197445

Implementation of JEP 181: Nest-Based Access Control

    XMLWordPrintable

Details

    • CSR
    • Resolution: Approved
    • P3
    • 11
    • hotspot
    • binary, behavioral
    • low
    • Hide
      The new JVM feature does not impact any existing class files, or any classes that do not make use of the new attributes.

      Recompilation with a new javac will produce different class files, leading to different reflection results (e.g., some bridge methods will no longer be generated).

      After recompilation, resolution of the top-level class may occur when it did not before, raising the possibility of errors (like ClassNotFoundError) that previously didn't occur. We found live examples of this when testing. Our strategy mitigates this risk by only attempting to load the nest host if necessary for access checking—so a new error would only occur if, at run time, one nested class attempts to access the private member of another nested class.

      The relaxation in the requirement to use invokespecial for private interface method invocations, means that code (specifically tests) that expects use of invokeinterface to be rejected, will now see it accepted.

      The change to interface method selection rules (to align with invokevirtual rules) means that code (specifically tests) that expected IllegalAccessError may now invoke an accessible overriding implementation, or throw a different exception if no such impleemntation exists.
      Show
      The new JVM feature does not impact any existing class files, or any classes that do not make use of the new attributes. Recompilation with a new javac will produce different class files, leading to different reflection results (e.g., some bridge methods will no longer be generated). After recompilation, resolution of the top-level class may occur when it did not before, raising the possibility of errors (like ClassNotFoundError) that previously didn't occur. We found live examples of this when testing. Our strategy mitigates this risk by only attempting to load the nest host if necessary for access checking—so a new error would only occur if, at run time, one nested class attempts to access the private member of another nested class. The relaxation in the requirement to use invokespecial for private interface method invocations, means that code (specifically tests) that expects use of invokeinterface to be rejected, will now see it accepted. The change to interface method selection rules (to align with invokevirtual rules) means that code (specifically tests) that expected IllegalAccessError may now invoke an accessible overriding implementation, or throw a different exception if no such impleemntation exists.
    • Java API, Class file construct, File or wire format
    • SE

    Description

      Summary

      JEP 181: Nest-Based Access Control

      Problem

      Closely-related classes sometimes need to share access private members. The Java language supports this, allowing access to all private members nested within the same top-level class. The JVM does not, requiring less-secure compiler workarounds and ad hoc solutions like Unsafe.defineAnonymousClass(). See JEP 181 for details.

      Solution

      A nest is a subset of classes in a package. Every class belongs to one nest (by default, a singleton nest containing only itself). Two classes belonging to the same nest are nestmates.

      Two new JVM attributes are introduced: NestHost and NestMembers. The first points to a class's nest host class (for example, the top-level class containing it); if there is no NestHost attribute, the class is its own nest host. The second, appearing in the nest host, enumerates the classes that are authorized to claim membership in a nest.

      The JVM access control rules are modified to allow access to private members from all of a class's nestmates. These checks occur on-demand: the nest host is not loaded (in order to consult its NestMembers attribute) until needed to grant access to an otherwise-inaccessible member.

      The source language compiler is responsible for deciding which classes and interfaces are nestmates. For example, the javac compiler places a top-level class or interface into a nest with all of its direct, and indirect, nested classes and interfaces. The top-level enclosing class or interface is designated as the nest host. The JVM itself simply defines an access control context based on these attributes with no regard to any language-level scoping or nesting characteristics. In the future, nestmates need not directly correspond to source language constructs.

      Traditionally, invokespecial is used to invoke private members, though invokevirtual also has this capability. Rather than perturb the complex rules about supertypes enforced by invokespecial, we require invocations of private methods in a different class to use invokevirtual. The invokeinterface instruction is enhanced to support invocation of private interface methods. In the process, we unify different method selection algorithms used by the JVM.

      The reflection API of java.lang.Class is enhanced to support nest-related queries.

      (The javac compiler is also updated to make use of nests, but this change does not impact any specifications. Some JLS changes are present to align the JLS description of runtime behavior with JVMS.)

      Minor clarifications and adjustments are needed in the core reflection and MethodHandle API's. These are mainly non-normative/descriptive text changes.

      MethodHandle.Lookup.findVirtual no longer throws IllegaAccessError if applied to a private interface method.

      The specifications for class redefinition and retransformation, in the JVM TI and JDWP specifications, along with the java.lang.instrument and com.sun.jdi API's are enhanced to disallow any modification of the NestHost or NestMembers attributes. For JDWP and JDI we also clarify the notion of restricted redefinitions.

      Specification

      Proposed changes to JLS and JVMS are attached. Full updated specifications and specdiffs are available as follows:

      Attachments

        1. nestmates-jls.html
          24 kB
        2. nestmates.html
          94 kB
        3. nestmates-jls.html
          22 kB
        4. nestmates.html
          97 kB
        5. nestmates-jls.html
          22 kB
        6. nestmates.html
          97 kB
        7. JEP-181-spec-changes.tar.gz
          475 kB
        8. JEP-181-spec-changes-May22.tar.gz
          427 kB
        9. JEP-181-spec-changes-June20.tar.gz
          494 kB
        10. JEP-181-spec-changes-June21.tar.gz
          494 kB

        Issue Links

          csr of

          Enhancement - null JDK-8010319 Implementation of JEP 181: Nest-Based Access Control

          • P3 - Major loss of function.
          • Resolved
          relates to

          Enhancement - null JDK-8204925 6.5: Clarify invokespecial

          • P4 - Minor loss of function, or other problem where easy workaround is present.
          • Open

          Activity

            People

              dholmes David Holmes
              jrose John Rose
              Karen Kinnear (Inactive), Maurizio Cimadamore
              Votes:
              0 Vote for this issue
              Watchers:
              7 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: