Type annotations for method/ctor reference expressions

[Michael Ernst]

Alex and Expert Group,

> The following productions occur in the latest spec for JSR 335 "Lambda
> expressions" (v0.6 - I will send a URL to a suitably-licensed file
> tomorrow):
>
> MethodReference:
>  ExpressionName '::' NonWildTypeArgumentsopt Identifier
>  Primary '::' NonWildTypeArgumentsopt Identifier
>  'super' '::' NonWildTypeArgumentsopt Identifier
>  TypeName '.' 'super' '::' NonWildTypeArgumentsopt Identifier
>  ReferenceType '::' NonWildTypeArgumentsopt Identifier
>
> ConstructorReference:
>  ClassType '::' NonWildTypeArgumentsopt 'new'
>  ArrayType '::' 'new'
>
> Some implications for JSR 308:
>
> 1. The NonWildTypeArguments term in MethodReference and
> ConstructorReference means that type arguments in method/ctor reference
> expressions are annotatable in source according to the current JSR 308
> grammar. (NonWildTypeArguments depends on ReferenceType, which the 308
> grammar makes annotatable.) For the class file, we have a target_type
> constant for method references, but there should be a separate constant for
> ctor references.

Right.

> 2. The ReferenceType term in MethodReference means that a type use there is
> annotatable in source. For the class file, a new target_type constant is
> needed.

Right.  I will add this.

> 3. The TypeName term in MethodReference should probably be annotatable in
> source. Come to think of it, what about annotating the TypeName in
> T.super.f (JLS 15.11.2)? Has JSR 308 missed this location all along?

This is not a use of a type; rather, it is a scoping mechanism.  Therefore,
it is not a target for a  type annotation.

> 4. The ClassType and ArrayType terms in ConstructorReference ought to be
> annotatable in source, but the JSR 308 grammar needs to be extended to
> allow this. Then new target_type constants are needed.

It would be nicer, from our point of view, for the production to be made:

  ConstructorReference:
   ReferenceType '::' NonWildTypeArgumentsopt 'new'

and it cleans up the grammar as well, avoiding the direct use of the
low-level productions ClassType and ArrayType.
Alex will suggest this change to the JSR 335 expert group.

		    -Mike