Parameter reflection: parameters with "" as their name

[Alex Buckley]

On 1/24/2013 1:00 PM, Peter Jensen wrote:
> 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?)

Default behavior of a JVM implementation is to enforce every normative 
clause in the JVMS unless the JVMS says otherwise. Here's an example of 
a normative clause: "... MethodParameters, which may appear only, and at 
most once, in the attributes table of a method_info structure". Another 
normative clause is that parameter_name_index is either 0 or points to a 
CONSTANT_Utf8_info.

I am aware that JVM implementers sometimes have difficulty with format 
checking of the "reflective" attributes (Signature, Runtime*Annotations, 
and now MethodParameters), but those issues should not be raised on this 
spec list.

> 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)).

To be precise, if there is a mismatch between parameters_count and the 
number of parameters in method_info.descriptor_index (see 8misc.pdf 
2.1), or if names are not well-formed parameter names, then core 
reflection should throw a ReflectiveOperationException.

Eric, what does the Reference Implementation currently do? (Remember 
this is not a GPL'd list.)

> 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).

I'm well aware of Unicode v. ASCII, but I want to keep things real 
simple for this Java SE 8 feature right now.

Alex