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

Peter Levart peter.levart at
Thu Dec 20 14:41:56 UTC 2012

On 12/20/2012 02:45 PM, Joel Borggrén-Franck wrote:
> Hi Peter, Eric and and others,
> Thanks for your comments,
> On 12/20/2012 09:09 AM, Peter Levart wrote:
>> 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.
> I would like to go the opposite way with Executable, Method, Field and 
> Parameter, like the caches work on Class instances in your patch.
> Reflective Objects should be created with non-initialized caches of 
> metadata. When someone wants to look at the metatdata we should check 
> the redefine count on Class, and update the caches if necessary. There 
> is already infrastructure for this in the VM for the old annotations 
> byte[] on Field, Method and Constructor.
That's good. So if someone has got a hold on a Method/Field/Constructor 
instance for a long time (for example some framework that caches 
reflective object itself), he/she/it will see annotations change between 
consecutive calls to the instance if they are re-defined.

Regards, Peter
> I am unclear if the parameter name is part of the signature, this is 
> significant because (IIRC) signaturs can not change in redefine, but 
> parameter annotations should be able to change.
> cheers
> /Joel

More information about the core-libs-dev mailing list