Summary

Correct some mishandling of method and field descriptor parsing from the last migration from generic parser to descriptor parser of java.lang.invoke.

Problem

The previous migration of method and field descriptor parsing from generic signature parser to descriptor parser in java.lang.invoke had a few significant issues:

1. It did not have proper filter for . presence in descriptor strings. So strings like Ljava.lang.Object; were erroneously accepted.
2. Invalid descriptors like L; or L/Missing; would result in TypeNotPresentException instead of GenericSignatureFormatError as before. (this would be a ClassFormatError in hotspot)
3. Using field type in the NameAndType for EnclosingMethod attribute would result in a spurious IllegalArgumentException in method descriptor parsing. (Hotspot validates NameAndType so all type strings must be valid field or method descriptor strings) This was previously GenericSignatureFormatError.

Solution

Fix these 3 omissions from the last migration. They now all cause GenericSignatureFormatError as before the migration.

In summary, the exceptions were thrown at the creation of annotation instances in AnnotatedElement methods, and Class::getEnclosingMethod, Class::getEnclosingConstructor, and Class::getEnclosingClass.

Annotation class value parsing exceptions currently include:

• GenericSignatureFormatError caused by IllegalArgumentException - for all descriptor format errors
• TypeNotPresentException - for if the class cannot be found

Enclosing exceptions include: (hotspot verification ensures the descriptor is a field or method descriptor, otherwise class loading fails and no Class instance is available)

• class resolution error as in JVMS 5.4.3.1 if the enclosing class cannot be resolved
• GenericSignatureFormatError caused by IllegalArgumentException - if the descriptor is a field descriptor
• TypeNotPresentException - for if a class in the descriptor cannot be found
• InternalError - if the nominal information indicates method/constructor as the reflective API (null otherwise), but the nominal info does not point to an existent method/constructor

There is no scenario in which the old parsing succeeds but the new parsing fail.

Specification

None. This is a purely implementation/behavioral change.