Generated parameter names for -parameters (JEP118)

[Jonathan Gibbons]

Jesper,

Thank you for your more detailed account.  There's definitely two issues 
here: the number of parameters, and the presentation.

-- Jon

On 05/29/2013 03: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
>