Review request JDK-8004729: Parameter Reflection API

[Joe Darcy]

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.

-Joe