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

Reply via email to