JSR 308 implementation: lambda

[Michael Ernst]

Alex-

I'm a bit uneasy about attaching formal parameter annotations for a lambda
on the invokedynamic bytecode.  The formal parameter annotations for any
other method don't go on the call, but where the formal parameter is
defined (in the method declaration).  The compiler will somehow translate
the formal parameter into a variable or expression.  The spec could simply
say that wherever such a variable or expression appears, it should have the
same annotation as was on the lambda's formal parameter declaration.  This
is similar to what the spec says about other code constructs that are
subject to optimization.

		    -Mike


> Subject: Re: JSR 308 implementation: information needs
> From: Alex Buckley <alex.buckley at oracle.com>
> To: type-annotations-dev <type-annotations-dev at openjdk.java.net>
> Date: Mon, 14 Jan 2013 16:09:00 -0800
>
> On 1/12/2013 4:51 AM, Michael Ernst wrote:
> > 3. We could use details about javac's translation of lambda, which will
> > greatly help us implement the (vague) JSR 308 spec for bytecode
> > representation of lambda type arguments that you and I agreed on in our
> > January 10 phone call.
>
> I spoke with Brian Goetz about the four interesting annotation locations:
>
> 1. The type of a formal parameter of a lambda expression.
>
>    { @Foo int x -> ... }
>
> 2. The "receiver" type of a method/ctor reference expression.
>
>    List<@Foo String>::size
>    ArrayList<@Foo String>::new
>
> 3. A type argument to the member of a method/ctor reference expression
>
>    Arrays::<@Foo String>sort
>    MyClass::<@Foo Integer>new
>
> 4. A type in a statement/expression in the body of a lambda expression
>
>    ... = { -> @Foo int x = 1; };
>
> For the lambda expression in 1 and the reference expression in 2/3, javac
> generates a single instruction whose execution will produce an object
> representing the lambda expression / method reference expression. The
> single instruction happens to be an invokedynamic with static arguments
> comprising two method handles and a method type - but none of that is
> guaranteed to be stable. The only stable fact - and this is likely to be
> true across compilers - is that a single instruction represents the
> "creation point" of a higher-order expression. The offset of that
> instruction should be stored in a target_info.
>
> For 4, the lambda body will be compiled to a method in some class of some
> package. Exactly which method is not relevant - type annotations in the
> lambda body should be compiled as if they were type annotations in the
> method body. Again, the "creation point" of the lambda expression is a
> single instruction, whose offset should appear in target_info.
>
> Alex