Generated parameter names for -parameters (JEP118)

Alex Buckley alex.buckley at
Wed May 29 15:28:58 PDT 2013

I agree with your assessment below. Either javac is not correctly 
generating the second parameters array entry, or javap is not correctly 
decoding it.

Note that when an entry appears in the parameters array for a parameter 
which was _not_ explicitly declared in source, you can "rely" on its 
ACC_MANDATED or ACC_SYNTHETIC flags - every Java compiler is compelled 
by the JLS to set them correctly. However, you cannot rely on the name 
or ACC_FINAL flag for such a parameter, for they are not specified and 
hence are compiler-specific.


On 5/29/2013 3:09 PM, Jesper Steen Møller wrote:
> Jonathan Gibbons wrote:
>> I think you should be more explicit in what you think is wrong,
>> instead of just posting a javap dump and expecting others to
>> read through it.
> I'm sorry -- you are quite right. I should have explained the problem properly.
> The problem is with the MethodParameters attribute for the anonymous inner class' constructor.
>> With respect to your question,
>> Why do you think an entry is missing from the table?
> The constructor code has three arguments: The this reference itself, the enclosing class' this reference, and the value of the captured final variable of the enclosing scope.
> The descriptor shows the two "non-this" arguments: (LParameterNames;Ljava/lang/String;)V
> As I understand, the MethodParameters attribute should describe the latter two parameters here, matching the method descriptor, but it doesn't quite:
> The hex dump of the MethodParameters table is this:
> MethodParameters: length = 0x5
> 02 00 0A 80 10
> ^^
> Length byte
>  From what I've read in '4.7.22 The MethodParameters Attribute', the length should be 9, since there's one byte for the length, and four bytes for each parameter.
> u1 parameters_count = 0x02
> parameters [2] = {
> parameter {
>    u2 name_index == 0x000A //  'this$0' in the constant pool
>    u2 access_flags == 0x8010 // meaning MANDATED+FINAL
>   },
> parameter {
>      // MISSING!
>    }
> }
> Also, I'm also suspecting that the entry is in error since javap didn't properly decode it and show the actual parameter names, as it can for other classes.
>> What entry do you think is missing from the table?
> The second one, containing the name of the captured local variable from the enclosing context. I'm sure this doesn't really have a name, since no code ac
> I'm expecting it to be synthetic and final 0x1010, but I could be mistaken.
> FWIW, this is from build 1.8.0-ea-b90.
> TIA, Jesper

More information about the compiler-dev mailing list