Review request JDK-8004729: Parameter Reflection API

Joe Darcy joe.darcy at
Fri Jan 18 07:07:08 UTC 2013

On 1/13/2013 9:30 AM, Eric McCorkle wrote:
> On 01/12/13 13:36, Joe Darcy wrote:
>> Hi Eric,
>> On 1/11/2013 9:14 PM, Eric McCorkle wrote:
>>> I got halfway through implementing a change that would synthesize
>>> Parameter's for the static links (this for the inner classes), when it
>>> occurred to me: is there really a case for allowing reflection on those
>>> parameters.
>>> Put another way,
>>> public class Foo {
>>>     public class Bar {
>>>       int baz(int qux) { }
>>>     }
>>> }
>>> Should baz.getParameters() return just qux, or should it expose
>>> Foo.this?  On second thought, I can't think of a good reason why you
>>> *want* to reflect on Foo.this.
>> You need to reflect on that parameter so you can call the constructor
>> properly using reflection :-)
> Alright, I will make the logic changes and post for review.
>>> Also, the logic is much simpler.  You just have to figure out how deep
>>> you are in inner classes, store that information somewhere, and offset
>>> by that much every time a Parameter calls back to its Executable to get
>>> information.  The logic for synthesizing the this parameters is much
>>> more complex.
>>> Thoughts?
>> We may need some more help from javac to mark parameters as synthesized
>> or synthetic, which can be done as follow-up work.  For inner classes
>> that are members of types, the outer this parameters are required to be
>> a certain way by the platform specification to make linkage work.
>> *However*, local and anonymous classes only have to obey a compiler's
>> contract with itself and are not specified.  In particular, not all such
>> inner classes constructors even have an outer this parameter.  For
>> example, with javac the constructor of an anonymous class in a static
>> initializer will *not* have an other this parameter.
> Is there any compelling reason that javac should generate information
> about the link parameters?  They don't have a name, and have standard
> modifiers (presumably final and synthesized).  It seems to me they ought
> to be synthesized by the reflection API.

Not all class files come from Java compilers of course and since core 
reflection implicitly acts on a class file level model rather than a 
source-level model, generally it is preferable (and in keeping with past 
practice) for core reflection to not try to get too clever in inferring 
missing information.


More information about the core-libs-dev mailing list