JDK-8067975 : 4.7.18: Specify a mapping from Signature and *Annotations attributes to method descriptors
  • Type: Bug
  • Component: specification
  • Sub-Component: vm
  • Affected Version: 8
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2014-12-19
  • Updated: 2018-11-02
  • Resolved: 2016-09-28
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 9
9Fixed
Related Reports
Relates :  
JDK-8213329 - Normalize inclusion of non-explicit parameters in JVM attributes
Relates :  
JDK-6559572 - Add a special case in JVMS for synthetic parameters of RuntimeVisibleParameterAnnotations
Relates :  
JDK-8020000 - Clarify "optional" attributes like EnclosingMethod and Signature
Description
JVMS7 and 8 specify that annotated parameters in the Runtime[In]VisibleParameterAnnotations attribute are counted against the method descriptor: "Each entry in the parameter_annotations table represents all of the run-time visible annotations on the declaration of a single formal parameter. ***The i'th entry in the table corresponds to the i'th formal parameter in the method descriptor (��4.3.3).***"

The intent was to allow annotations on any parameter physically present for the method, regardless of whether the parameter was explicitly declared in Java source code or generated by a compiler in an implementation-specific manner ("synthetic").

However, javac has never emitted Runtime[In]VisibleParameterAnnotations attributes that follow the method descriptor. Where the method descriptor contains implicitly declared parameters ("mandated"), javac ignores them for the purpose of generating a parameter_annotations table. For example, the <init> method of an inner class has a method descriptor whose first parameter descriptor represents an implicitly declared parameter (see JLS8 8.8.1), so javac generates parameter_annotations[0] to store annotations for the second parameter descriptor, representing the first _explicitly_ declared parameter.

javac takes a similar position in Signature attributes: method signatures denote formal parameters which were explicitly declared or neither-explicitly-nor-implicitly declared, and completely ignore any implicitly declared parameters introduced by the JLS.
Comments
JVMS 4.7.18 and 4.7.19 could say, for the parameter_annotations table, that the entries in the table correspond to those parameter descriptors in the method descriptor which denote either explicitly declared parameters or neither-explicitly-nor-implicitly declared parameters. Parameter descriptors which denote implicitly declared parameters do not correspond to any entry in the table. JVMS 4.7.20.1 could say: - For formal_parameter_target: "The value of the formal_parameter_index item specifies which formal parameter declaration has an annotated type. ***A formal_parameter_index value of 0 specifies the first formal parameter which is either explicitly declared or neither-explicitly-nor-implicitly declared. (The formal_parameter_target item records that a formal parameter's type is annotated, but does not record the type itself. The type may be found by inspecting the method descriptor (��4.3.3) of the method_info structure enclosing the RuntimeVisibleTypeAnnotations attribute; in particular, by inspecting the parameter descriptors which denote either explicitly declared parameters or neither-explicitly-nor-implicitly declared parameters.)***" - For empty_target, a new note: "If the method_info structure enclosing the RuntimeVisibleTypeAnnotations attribute represents the <init> method of a class identified as a non-ACC_STATIC nested class by its InnerClasses attribute, then the receiver type may be found by inspecting the parameter descriptor which denotes an implicitly declared parameter (4.3.3). For all other method_info structures, the receiver type may be found by inspecting the first parameter descriptor which denotes either an explicitly declared parameter or neither-explicitly-nor-implicitly declared parameter." JVMS 4.7.9.1 could say: "A method signature encodes ... It describes any type parameters of the method; the (possibly parameterized) types of any formal parameters ***(excluding implicitly declared parameters)***; the (possibly parameterized) return type, if any; and the types of any exceptions declared in the method's throws clause ***(excluding implicitly declared exceptions)***." All that said, I am uncomfortable about embedding such voluminous compiler detail into the JVMS. Instead, I will note the complexity of attribute-to-descriptor mappings, and use the example of an inner class's ctor (with its implicitly declared parameter) for why a parameter descriptor might exist without corresponding to anything in a method signature/annotated parameter list. (Separately, 4.7.9 should constrain the cardinality of the Signature attribute.)
24-09-2015
JVMS 4.3.3 could specify what is denoted by each parameter descriptor in a method descriptor. This depends on the kind of method: - For the <init> method of a class identified as a non-ACC_STATIC nested class by its InnerClasses attribute, the first parameter descriptor denotes an implicitly declared parameter (JLS 8.8.1), and each subsequent parameter denotes either an explicitly declared parameter or a neither-explicitly-nor-implicitly declared parameter. - For the <init> method of a class with flag ACC_ENUM, the first and second parameter descriptors denote neither-explicitly-nor-implicitly declared parameters (JLS 8.9.2), and each subsequent parameter denotes either an explicitly declared parameter or a neither-explicitly-nor-implicitly declared parameter. - For all other methods, each parameter descriptor denotes either an explicitly declared parameter or a neither-explicitly-nor-implicitly declared parameter. All that said, while it's useful to have this information recorded here, it's so particular to corner-case Java constructors that I'm not convinced it should be in the JVMS.
24-09-2015