Removing target_type distinctions between constructors and methods

[Alex Buckley]

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