Method Parameter Reflection spec

[Eric McCorkle]

Okay, strike #2 from my requests.  What about having
Executable.getParameters() throw ReflectiveOperationException instead of
methods in Parameter, for the reasons I discuss?

On 08/19/13 18:12, Alex Buckley wrote:
> The 8misc.pdf file doesn't say anything about bad constant pool indexes.
> 
> If MethodParameters was an attribute that the JVM is required to
> recognize and correctly read, then the JVM would be required to throw
> ClassFormatError for bad constant pool indexes. But since
> MethodParameters is an attribute that the class libraries of the Java SE
> platform - as opposed to the JVM - are required to recognize and
> correctly read, it's the responsibility of the class libraries to throw
> something which is a) useful and b) consistent with bad constant pool
> indexes for similar situations such as AnnotatedElement#getAnnotations
> on a RuntimeVisibleAnnotations attribute.
> 
> How the class libraries interact with a JVM implementation to determine
> good or bad constant pool entries (e.g. private functions of the JVM
> implementation throw IllegalArgumentException, which
> AnnotatedElement#getAnnotations then wraps as a FooBarException) is not
> a matter for the SE API specification. The only thing that matters for
> the SE API specification is what something like
> AnnotatedElement#getAnnotations is specified to throw today.
> 
> Alex
> 
> On 8/19/2013 2:57 PM, Eric McCorkle wrote:
>> The current version of the spec indicates that methods in
>> java.lang.reflect.Parameter should throw ReflectiveOperationException
>> for several cases (wrong number of parameters, bad parameter name, bad
>> constant pool index).
>>
>> I'd like to suggest two (separate) minor revisions:
>>
>> 1) Executable.getParameters() should throw the
>> ReflectiveOperationException in the case of an invalid name or the wrong
>> number of parameters.  The rationale is as follows:
>>
>>   * Doing it this way makes it straightforward to implement
>> j.l.r.Parameter as an immutable object.  Having methods in Parameter
>> throw the exception means Parameter objects will have to remember
>> whether or not they have verified their name (or else verify the name
>> every time they are called).
>>
>>   * Having every single method in Parameter possibly check whether the
>> number of parameters that were returned from the VM is correct seems
>> rather awkward, as opposed to having a single check when Executable
>> obtains the Parameter array back from the VM.
>>
>> 2) In the event of a bad constant pool index, an
>> IllegalArgumentException.
>>
>>   * The current behavior of hotspot whenever it expects a UTF-8 constant
>> pool entry, but sees either an out-of-bounds index or something other
>> than a UTF-8 is to throw an IllegalArgumentException.
>>