Well, for one, Lambdas are desugared into methods, not anonymous classes. Early on they used anonymous classes because it was convenient but that wasn't the final translation strategy.

http://cr.openjdk.java.net/~briangoetz/lambda/lambda-transla...

My impression from the openjdk code is that each lambda generates:

1. A method in its parent class. 2. An invokedynamic instruction at the call site.

The invokedynamic instruction calls LambdaMetafactory, which compiles an anonymous class at runtime that calls method #1. So the only benefit of using invokedynamic is fewer class files, by deferring generating them until runtime.

Non-capturing lambdas also don't instantiate a new object at each call site. But this is also doable without invokedynamic.

Yes, and these methods create an anonymous class at runtime. What's so hard to understand about this?

It was a misunderstanding on my part about where they were claiming the anonymous class was generated. Early versions of Lambda were nothing more than sugar on top of anonymous inner classes and the claim above sounded very similar to that. However, I see that inside the LambdaMetaFactory anonymous classes are generated based on the call site. Probably the biggest difference is that Java 8 can avoid an object allocation when the lambda doesn't capture. Not sure if Scala supports this but I'm sure that it could do it.