Method Parameter Reflection spec

[Alex Buckley]

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