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

Migrate descriptor parsing from generics to BytecodeDescriptor

XMLWordPrintable

    • Icon: CSR CSR
    • Resolution: Unresolved
    • Icon: P4 P4
    • 26
    • core-libs
    • None
    • behavioral
    • minimal
    • Some previously accepted but illegal descriptor strings are now rejected. Such strings would already fail when consumed by other tools.
    • Java API
    • Implementation

      Summary

      Introduce more accurate parsing of descriptor strings in core reflection.

      Problem

      Using a generic string parser to parse descriptor strings is inaccurate; it may accidentally accept generic strings. In addition, we aim to remove this legacy generic string parser, known to be erroneous sometimes, in the future to reduce maintenance cost around evolution of signatures.

      The legacy parser usage occurs in reflection for the EnclosingMethods attribute and the annotation structures in the class file format.

      Solution

      We can reuse BytecodeDescriptor since it is behaviorally compatible, including exceptional contracts. Migrating to BytecodeDescriptor would also align JDK's handling of the descriptor strings closer to that by other tools or consumers of class files.

      Specification

      None. This is a purely implementation/behavioral change. (!) marks the changes.

      In both EnclosingMethod and annotations:

      • (!) Some behavioral changes are that signature inputs that previously cause MalformedParameterizedTypeException or ClassCastException now cause TypeNotPresentException. For example, Ljava/util/Optional<**>;(two type arguments when only one type parameter is declared, now a class name java/util/Optional<**>) or Ljava/util/Optional<*>; (type argument presence, now a class name java/util/Optional<*>).
      • Interestingly, some signatures like Ljava/util/Map.Entry; compliant with JVMS already failed in the existing parser with GenericSignatureFormatError, and the failure is preserved by the new parsing.

      In EnclosingMethod:

      • (!) There is new IllegalArgumentException thrown if the type string is a field descriptor string. (Previously it was a GenericSignatureFormatError)
      • Note the hotspot JVM already blocks non-field/method type strings in a name and type CP entry in verification with a ClassFormatError.

      In annotations:

      • (!) Some inputs that previously caused ClassCastException now cause GenericSignatureFormatError, such as TT;

      All such strings are already expected to fail already in the descriptor parsers in other tools.

            liach Chen Liang
            liach Chen Liang
            Roger Riggs
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated: