Parameter reflection: parameters with "" as their name

[Peter Jensen]

On 01/24/13 12:35, Alex Buckley wrote:
> // See new recipients of this mail.
>
> // No re-posting of content between lists with different licenses, 
> please.
>
> On 1/24/2013 11:33 AM, Eric McCorkle wrote:
>> The current version of the spec for parameter reflection, found here:
>>
>> http://cr.openjdk.java.net/~abuckley/8misc.pdf
>>
>> states that if a parameter has no name, then the reflection API should
>> synthesize a name of the form "argN", where N is the index of the
>> parameter.  It also states that if a MethodParameters attribute has a
>> name index of 0, then it indicates a parameter with no name.
>>
>> The question I have is, what if a MethodParameters attribute indicates a
>> name of "" (meaning, the empty string)?  Does this count as a valid
>> name, or should it be treated as a parameter with no name?
>
> For simplicity, I would be OK with saying that the name of a method 
> parameter is an "unqualified name" per JVMS 4.2.2. That bans . ; [ / 
> and allows everything else. For compilers targeting the ClassFile 
> format, this is a reasonable trade-off between freedom and convention.
>
> I would also say that an unqualified name (regardless of its role as a 
> field name, parameter name, etc) must consist of at least one ASCII 
> character in addition to not containing certain characters. That is, 
> I'm happy to declare "" out of bounds for MethodParameters to avoid 
> confusion with a 0 index (which I think remains a useful escape hatch 
> for compilers).
>
> How does all that sound?

The VM will not enforce any rules, I presume. The spec says it doesn't 
enforce the parameter_count restriction, and I presume it
doesn't enforce any name restrictions (unless it already does so 
generally for constant pool entries?)

The reflection API doesn't say how it deals with broken restrictions. 
For instance,
- does it supplement missing arguments, as if they have no names
- does it silently ignore extra names, or does it report all names present.
- if you define any restrictions on the content of names, how does the 
API deal with broken names
   (e.g. does it remove none printable characters (e.g. backspace)).

Note: I don't see a reason to give "" a special treatment. As far as I'm 
concerned, that's just one
more whitespace than "\u0008". The later may actually be useful, since 
the toString() specification
mandates a space before the parameter name:-)

And why at least one ASCII character? That's not I18n friendly

On the other hand, allowing any string as-is may not be safe (e.g. a 
bunch of control characters).

>
> Alex