- There should be a consistent style for describing the cardinality of an attribute. (Rather than "may have at most one", "may have no more than one", "can be no more than one".)

- 4.7.2 ConstantValue and 4.7.3 Code attributes traditionally said, in their sections, that "Every JVM implementation must recognize ... attributes." This should be removed since it duplicates a statement in 4.7 that identifies ConstantValue, Code, and Exceptions as the core attributes required for correct class file interpretation. (The Exceptions attribute section traditionally omitted the "Every JVM implementation ..." clause, thus highlighting the main danger of repeating information: it can be repeated inconsistently.)

- 4.7.4 StackMapTable needs to be fundamentally reorganized for clarity: i) define the attribute format before the concept of stack map frames, ii) remove mention of type state since it is not relevant here, iii) explain "bytecode offset" and "verification type" before enumerating the types of stack map frame, iv) fix the appallingly inconsistent terminology (entities on the stack are described at various times as items, entries, and elements).

(4.7.4 said that a stack map frame specified an offset (explicitly or implicitly) as well as verification types for locations. It then defined both "stack map frame" and "type state" as a mapping from locations to types, and said the terms were interchangeable. One might wonder where offsets live in this mapping, but since a stack map frame merely "specifies" an offset, one might get by with the idea that an offset is "outside" the mapping embodied by a stack map frame/type state yet still applies to it. That's fine until 4.10.1.3, where a stack map frame is explicitly defined as a entity enclosing a type state. Now they don't look so interchangeable. 4.10.1.6 continues: "If we have a stack map and an incoming type state, the type state must be assignable to the one in the stack map. We may then proceed to type check the rest of the stream with the type state given in the stack map." It's pretty clear that a stack map frame is in fact a different kind of thing than a type state.)

- 4.7.6 InnerClasses said "If the constant pool of a class or interface C contains a CONSTANT_Class_info entry which represents ..." but this can be interpreted as contains-exactly-one CONSTANT_Class_info entry. In fact, the rule means to say "at least one CONSTANT_Class_info entry".

- 4.7.16 RuntimeVisibleAnnotations has an unfortunate error which crept in during the JSR 924 Maintenance Review in 2011. annotations[].element_value_pairs[].element_name_index is said to be a "CONSTANT_Utf8_info structure (��4.4.7) representing a valid field descriptor (��4.3.2) that denotes the name of the annotation type element" ... in fact just a simple name is required, not a field descriptor. The error is due to 6874250.