lambda and MethodHandles in current prototype

[Brian Goetz]

>> You seem to be imploying that it is beneficial to specify the behavior
>> more tightly.  Why is this good?  Is is simply that you want to know
>> whether an object is the result of a lambda expression (and if so, what
>> would you do with this information?), or something more?
>
> No, I was just wondering whether the implementation philosophy has changed sice last time I checked.

Right, the implementation just has not yet caught up with the philosophy.

> And now that I have checked, ...
>
> ... I found your presentation at: http://www.wiki.jvmlangsummit.com/images/1/1e/2011_Goetz_Lambda.pdf

If you're interested, there's also a video of that talk online.

> Just a question: Is current prototype already using this "MetaFactory" to construct converted objects? Is this "MetaFactory" pluggable if one wants to experiment with different strategies? Just curious.

Not yet.  But I believe the prototype compiler is currently using a 
metafactory-like approach, at least in that it vectors the SAM 
conversion through an invokedynamic (whose bootstrap just invokes the 
proxy code that was used previously), but not one that implements the 
full generality of the metafactory (yet).

Somewhere in the next few months this will get hooked up, and it will 
indeed be possible to experiment with different metafactory 
implementations.  Obvious candidates include:
  - Spinning "inner classes" dynamically (one class per callsite)
  - Spinning per-SAM wrappers dynamically (one class per SAM)
  - Method handle proxies
  - VM-internal object-construction APIs

FWIW, the monkey wrench in implementing any of these is serialization. 
We have not yet worked out all the details here.