JSR 308 implementation: information needs

[Alex Buckley]

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