Details

      Description

      JEP 371 introduces hidden classes in Java 15. Hidden classes have the following implications to existing code:

      1. `Class::getName` traditionally returns a binary name, but for a hidden class it returns a string that contains an ASCII forward slash (`/`) and is therefore not a binary name. Programs that assume the returned string is a binary name may need to be updated to handle hidden classes. That said, the longstanding practice of `Unsafe::defineAnonymousClass` was to define classes whose names were not binary names, so some programs may already handle such names successfully.

      2. `Class::descriptorString` and `MethodType::descriptorString` returns a string that contains a ASCII dot (`.`) for a hidden class and therefore is not a type descriptor conforming to JVMS 4.3. Programs that assume the returned string is a type descriptor that conforms to JVMS 4.3 may need to be updated to handle hidden classes.

      3. `Class::getNestMembers` is changed to not throw an exception when it fails to validate a nest membership of any member listed in `NestMembers` attribute. Instead, `Class::getNestMembers` returns the nest host plus the members listed in the host's `NestMembers` attribute that are successfully resolved and determined to have the same nest host as this class. (This means it may return fewer members that listed in `NestMembers` attribute.) Existing code that expects `LinkageError` if there is a bad nest membership may be impacted.
                      
      4. The nestmate test in the JVM is changed to throw only `IllegalAccessError` when the nest membership is invalid. Some historical understanding is necessary:
      - In Java 8, every access control failure was signaled with `IllegalAccessError` (IAE). Moreover, if a given access check failed with IAE once, then the same check would fail with IAE every time.
      - In Java 11, the introduction of nest mates (JEP 181) meant that an access control failure could be signaled either with `IllegalAccessError` or, if nest membership was invalid, `LinkageError`. Still, if a given access check failed with a specific exception, then the same check would always fail with the same exception.
      - In Java 15, the introduction of `Lookup::defineHiddenClass` implies that the nest host of the lookup class must be determined eagerly, when the hidden class is defined as a nestmate of the lookup class. Both `Lookup::defineHiddenClass` and `Class::getNestHost` both determine the nest host of a class in a more resilient manner than the JVM did in Java 11; namely, the API simply treats a class as self-hosted if its purported nest membership is invalid. For consistency with the API, the JVM no longer throws `LinkageError` when a class's nest membership is invalid, and instead treats the class as self-hosted. This means that the JVM only ever throws IAE from access control (because a self-hosted class will not permit any other class to access its private members) -- this is the behavior expected by the vast majority of user code.

      5. JVM TI `GetClassSignature` returns a string that contains a ASCII dot (`.`) for a hidden class. JVM TI agents may need updating for hidden classes if they assume the returned string from `GetClassSignature` is a type descriptor conforming to JVMS 4.3.
                                                          

        Attachments

          Activity

            People

            • Assignee:
              mchung Mandy Chung
              Reporter:
              mchung Mandy Chung
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: