-
CSR
-
Resolution: Unresolved
-
P4
-
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 namejava/util/Optional<**>
) orLjava/util/Optional<*>;
(type argument presence, now a class namejava/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.
- csr of
-
JDK-8356022 Migrate descriptor parsing from generics to BytecodeDescriptor
-
- Resolved
-