-
Bug
-
Resolution: Unresolved
-
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