Parameter reflection: parameters with "" as their name

[Joseph Darcy]

Hello,

 From earlier in the thread, I don't think it would be reasonable to 
*require* an ASCII character in a parameter name (there is no such 
requirement in Java source code), but I see that restriction is *not* in 
the current specification.

Cheers,

-Joe

On 1/24/2013 4:12 PM, Alex Buckley wrote:
> On 1/24/2013 3:24 PM, Eric McCorkle wrote:
>> On 01/24/13 16:53, Alex Buckley wrote:
>>> 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.)
>>
>> The reference implementation (which is under active testing and fixing)
>> presently reports whatever is in the MethodParameters attribute, and
>> will not throw an exception; however, this is going to change very soon.
>
> OK. In anticipation of developments in this area, I have uploaded a 
> new spec PDF which constrains parameter names and requires that core 
> reflection must detect ill-formed items in MethodParameters. See:
>
>   http://cr.openjdk.java.net/~abuckley/8misc.pdf
>
> There is also a change to the structure of MethodParameters itself 
> (sorry). u4 parameter_flags is now u2 access_flags. The reason for 
> u4->u2 is that the last unused bit in a u2 access_flags - 0x8000 - is 
> now available to denote ACC_SYNTHESIZED. This is a very pleasing 
> development.
>
> (See the discussion in the previous PDF, 
> http://cr.openjdk.java.net/~abuckley/8misc-20130109.pdf, for why 
> 0x8000 was not available previously.)
>
> Finally, there is a clarification w.r.t. @Target for 
> repeatable/containing annotation types.
>
> Alex