[type-annos-observers] Removing target_type distinctions between constructors and methods

[Jonathan Gibbons]

If the values are distinct for constructor and method, that implies 
someone would have to check them, meaning that someone would have to 
check things like "0x46 method reference receiver" was not used on an 
<init> method, etc.   Simpler is better, as long as it really is simpler 
overall.

-- Jon



On 05/03/2013 02:35 PM, Alex Buckley wrote:
> I am fine with keeping the target_type values as they are.
>
> There are no ctors in a ClassFile, only methods, so type annotations 
> connected with a ctor declaration are stored under a method_info. If 
> the first table in figure 1 had a target_type 0x02 "constructor type 
> parameter", would the method_info have to be an instance 
> initialization method? (Repeat as necessary if the second table had 
> target_type values for "constructor return type" et al.) Not worth 
> checking. Core reflection can perfectly well understand that an 
> annotated method type parameter for an instance initialization method 
> should be exposed as an annotated constructor type parameter.
>
> Things are slightly trickier with the third table. A ctor invocation 
> in the Code attributes differs significantly from a method invocation. 
> We may yet see ctor reference expressions deviate in syntax or 
> implementation from method reference expressions. Having distinct 
> target_type values doesn't strike me as "wrong", so I'm happy to keep 
> them.
>
> Alex
>
> On 4/17/2013 7:23 AM, Michael Ernst wrote:
>> Currently, the Type Annotations (JSR 308) Specification uses different
>> TargetType enum constants and target_type values for constructors and
>> methods.  For example, here are target_type values:
>>
>> 0x45  constructor reference receiver
>> 0x46  method reference receiver
>>
>> 0x48  type argument in constructor call
>> 0x49  type argument in method call
>>
>> 0x4A  type argument in constructor reference
>> 0x4B  type argument in method reference
>>
>> These distinctions seem irrelevant.  You can tell whether an annotation
>> relates to a constructor or method from where it appears in the class 
>> file,
>> so it doesn't seem to be necessary to also encode this in target_type.
>>
>> Perhaps these distinctions were put in the JSR 308 spec because an 
>> earlier
>> version of the lambda spec made these distinctions in its grammar (and
>> possibly elsewhere).
>>
>> I propose that we eliminate this distinction, using only 3 instead of 6
>> target_type values and TargetType enum constants.  I'd like to hear
>> reactions from others (both on and off the Expert Group) before 
>> making this
>> change, though.  Thoughts?
>>
>>               Thanks,
>>
>>              -Mike