Review request:Updated JDK-8004728 Implement core reflection API for parameter reflection (original) (raw)

Peter Levart peter.levart at gmail.com
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