Lambda translation

[Brian Goetz]

Thanks for the corrections.  More inline.

> In section "varargs", there is no need for a bridge
> because if the strategy is "inner classes", the bridge code
> can be inserted in the generated method of the proxy
> and if the strategy uses method handle you can use
> regular combiners.

Right, at first I thought this argument was a slam-dunk for "do all the 
work in the metafactory" (given that MethodHandle.asType can do a 
varargs transformation.)  But as I worked through the details on when a 
call is a varargs call and when it is not, I realized that there is 
information the compiler has that is harder to reconstruct at runtime. 
I think this one is one which will look warty either way, whether we do 
some/all/none of the work in the compiler and the remaining 
some/none/all in the runtime.

> For method reference, it's more complex because the compiler can't add
> the ACC_LAMBDA after the fact, perhaps only public method of public class
> can be serialized.

Yep, this is one of the considerations that drove me to prefer the 
proposed approach -- it doesn't result in weird restrictions on what the 
user can do, nor does it result in strange sometimes-public, 
sometimes-private desugarings.  Also avoids the "public sidecar class" 
problem that some of the other approaches would have required in some cases.

And, all of this will have to be thoroughly explored by the security 
experts.