- 
    Bug 
- 
    Resolution: Unresolved
- 
     P4 P4
- 
    8
A better approach is to identify *throughout* Chapter 4 the assertions about the class file format that constitute format checks. My suggested approach is to carefully use the word "must" in Chapter 4 iff a format check is being described.
Based on some testing of Hotspot behavior and desire to keep things simple, some suggested behavioral changes:
- Eliminating checks on CONSTANT_NameAndType structures involving restricted method names (names that include < or >) and name/descriptor coordination (4.4.6). These checks should only occur when the constant is referenced from a context that requires a method.
- Ensuring that a CONSTANT_InvokeDynamic structure never uses method name <init> (4.4.10), rather than delaying the check until an invokedynamic instruction is verified.
- Rejecting class or interface declarations with Module, ModulePackages, or ModuleMainClass attributes (4.7.25, 4.7.26, 4.7.27), and non-static field declarations with ConstantValue attributes (4.7.2).
- relates to
- 
                    JDK-8233863 4.7: Simplify and clarify the rules for optional attribute validation -           
- Open
 
-         
- 
                    JDK-8322650 4.7.25, 4.7.26, 4.7.27: reject class/interface declarations with module-related attributes -           
- Open
 
-         
- 
                    JDK-8323550 4.9, 4.10: Clarify timing of code validation checks -           
- Open
 
-         
- 
                    JDK-8233861 5.3: Clean up class loading specification -           
- Closed
 
-         
- 
                    JDK-8322655 Allow NameAndType constants with special method names -           
- Closed
 
-         
- 
                    JDK-8267650 Better-defined JVM class file validation -           
- Closed
 
-         
- 
                    JDK-8322651 4.7.2: reject ConstantValue attributes on non-static fields -           
- Open
 
-         
