JSR 308 implementation: lambda

[Alex Buckley]

The invokedynamic causes _creation_ of the lambda expression, not the 
_invocation_ of the lambda expression's body. The object resulting from 
lambda expression creation may or may not ever be used to achieve an 
invocation of the lambda expression's body.

Still, you're right that a lambda expression converts to a method 
_somewhere_, and the formal parameters of that method are related in a 
compiler-specific way to the formal parameters of the lambda expression. 
An annotation on the type of a formal parameter of the lambda expression 
could become an annotation on the type of the corresponding formal 
parameter of the method, true.

You use the word "declaration" below; but only the type, not the 
declaration, of a formal parameter of a lambda expression is to be 
annotatable. You also use the word "optimization"; that word has no 
meaning in the context of compiling lambda expressions, since compiling 
lambda expressions is _nothing like_ compiling other Java language 
constructs.

Alex

On 1/15/2013 1:24 PM, Michael Ernst wrote:
> 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