JVMS7 defines signatures in 4.3.4 but they are not read or used by the JVM. Signatures occur in two attributes (Signature and LocalVariableTypeTable) solely to support core reflection and compilation with class files. Accordingly, their billing in 4.3.4 is far too prominent. They should be defined in 4.7.9 (the Signature attributes), which 4.7.14 (the LocalVariableTypeTable attribute) should reference.

Without in any way changing the format of signatures, their narrative can be clarified by drawing a distinction between "signatures" (which encode the type of a class, method, or field declaration) and "type signatures" (which represent the types which appear in "signatures"). For example, a "class signature" encodes the declaration of a class, while a "class type signature" represents the type of the superclass in the class signature. In this pursuit, FieldTypeSignature and MethodTypeSignature should be renamed FieldSignature and MethodSignature. They, and ClassSignature, will refer to ReferenceTypeSignature, the general representation of a (possibly parameterized) class type, array type, or type variable. TypeSignature, the root of the type signature hierarchy, can be renamed JavaTypeSignature to reinforce that signatures are a Java language view. FormalTypeParameters can be renamed to TypeParameters since that's the JLS term.

Separately, JVMS7 noted in 4.7.9 that Oracle's JVM implementation does not check well-formedness of signatures in the Signature attribute. This means the clause in 4.7 about recognizing the Signature attribute is too strong. 4.7 should move Signature to the list of 49.0 attributes (RuntimeVisibleAnnotations et al) which must be recognized solely "in order to properly implement the Java SE platform class libraries".