brian.goetz at oracle.com
Sun Apr 22 14:05:13 PDT 2012
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
More information about the lambda-dev