Parameter reflection: parameters with "" as their name

[Paul Benedict]

Why wait until runtime to discover ill-formed parameter names? Wouldn't it
be better to catch these at verification time?
On Jan 24, 2013 6:13 PM, "Alex Buckley" <alex.buckley at oracle.com> 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<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<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
>