-
Bug
-
Resolution: Unresolved
-
P4
-
21, 22, 23
A CONSTANT_InvokeDynamic references a CONSTANT_NameAndType. It is required, via format checking, that "the indicated descriptor must be a method descriptor". However, there is no stated restriction on the *name* portion of the NameAndType.
Because 'invokedynamic' is meant to mimic a method call, a reasonable expectation is that the rules governing the NameAndType of a Methodref from an invokestatic would apply here: the name must be a valid *method name* (4.2.2), and must not be '<clinit>' or '<init>' (in other words, the name must not make any use of '<' or '>').
I don't believe JVMS currently asserts any restrictions about invalid method names (e.g., '<foo>' or 'x>y'); it does prohibit the names '<clinit>' and '<init>' on verification of an 'invokedynamic' instruction.
In JDK 13, Hotspot allows a method named <init> if the descriptor is ()V, subsequently rejecting the method name at verification time. Since we already know this NameAndType is intended to be used by an invokedynamic, it doesn't make much sense to defer half of the check. (Compare the validation of MethodHandle structures (4.4.8), which also enforces verification-style constraints during format checking on use of the name <init>.)
To simplify, I propose enforcing a format check for CONSTANT_InvokeDynamic that the name be a valid, non-special method name.
Because 'invokedynamic' is meant to mimic a method call, a reasonable expectation is that the rules governing the NameAndType of a Methodref from an invokestatic would apply here: the name must be a valid *method name* (4.2.2), and must not be '<clinit>' or '<init>' (in other words, the name must not make any use of '<' or '>').
I don't believe JVMS currently asserts any restrictions about invalid method names (e.g., '<foo>' or 'x>y'); it does prohibit the names '<clinit>' and '<init>' on verification of an 'invokedynamic' instruction.
In JDK 13, Hotspot allows a method named <init> if the descriptor is ()V, subsequently rejecting the method name at verification time. Since we already know this NameAndType is intended to be used by an invokedynamic, it doesn't make much sense to defer half of the check. (Compare the validation of MethodHandle structures (4.4.8), which also enforces verification-style constraints during format checking on use of the name <init>.)
To simplify, I propose enforcing a format check for CONSTANT_InvokeDynamic that the name be a valid, non-special method name.
- relates to
-
JDK-8322655 Allow NameAndType constants with special method names
- Closed