How far to go in replacing inner classes with lambdas?

[Brian Goetz]

> The r -> r.run() refactoring looks OK to me provided it is not
> transforming a static nested class into an inner class.

Actually, the compiler doesn't generate an extra class at all.  It 
generates a method for the body, some metadata in the constant pool 
describing the target type (e.g., Executor), and an invokedynamic to 
create the lambda object.

With the current (naive) runtime translation strategy, the generated 
class is a static one, and further, for stateless (non-capturing) 
lambdas, all evaluations of the same lambda expression are translated to 
the same cached object -- with that cached object being lazily 
initialized on first capture.

So, if you say
   Executor e = r -> r.run();

at runtime, there will only be one instance of that lambda, no matter 
how many times the above line of code is executed.