Removing target_type distinctions between constructors and methods
alex.buckley at oracle.com
Fri May 3 14:35:50 PDT 2013
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.
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?
More information about the type-annotations-spec-experts