Method Parameter Reflection spec

[Alex Buckley]

The precedent is AnnotatedElement#getAnnotations as found in Class, 
Field, Executable, etc. Do those methods validate the 
RuntimeVisibleAnnotations attribute before returning an array of 
Annotation objects? I think they do. Can you describe the validation 
they do which may cause an AnnotationTypeMismatchException or 
IncompleteAnnotationException?

If their validation is "equivalent" to what Executable#getParameters 
would do, then it would be acceptable to change the spec and 
implementation of Executable#getParameters and 
Parameter#getName/Type/etc at this late stage. Please comment ASAP.

Alex

On 8/20/2013 12:10 PM, Eric McCorkle wrote:
> 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.
>>>