Review request:Updated JDK-8004728 Implement core reflection API for parameter reflection

[Peter Levart]

Hi Eric and others,

I'd also like to rise an internal design concern regarding construction 
of Parameter objects. Currently raw reflection data for Executable 
objects is obtained from the VM atomically - the whole Method or 
Constructor is fully constructed with all necessary information in one 
go. That's true also for parameter types and parameter annotations. New 
Parameter API is now "pulling" lazily some additional information from 
the VM (parameter names and modifiers). How does this play together with 
class re-definitions/re-transformations? Is it possible that a class 
re-definition changes parameter names? Can it change parameter annotations?

Imagine one has a reference to a Method, that has since it's 
construction already been re-defined in the VM (for example a parameter 
name and annotation has changed).  When asking for annotations on the 
re-defined parameter, you will get annotations that were actual at the 
time the Method was constructed, but when asked for the parameters and 
their names, you will get the already redefined names.

I think that the more correct implementation would construct 
Method/Constructor objects in the VM with all the necessary information 
(parameter names and modifiers) already present in the Executable 
objects. This information could be conveniently packed and only unpacked 
and expanded on user's request - like annotations.

Regards, Peter

On 12/19/2012 11:43 PM, Eric McCorkle wrote:
> Hello,
>
> Please review the implementation of the core reflection API for method
> parameter reflection.  This changeset introduces a new class, Parameter,
> which represents information about method parameters.  It introduces a
> new method into Executable which returns an array of the parameters for
> the method or constructor represented by the Executable.
>
> This is part of a larger set of changes which implement portions of the
> method parameter reflection functionality in hotspot and javac.
>
>
> The open webrev is here:
> http://cr.openjdk.java.net/~jgish/~emccorkl/webrev/JDK-8004729/
>
>
> The feature request is here:
> http://bugs.sun.com/view_bug.do?bug_id=8004729
>
>
> The latest version of the spec can be found here:
> http://cr.openjdk.java.net/~abuckley/8misc.pdf
>
> Thanks,
> Eric