Updated State of the Lambda

[Brian Goetz]

> I have some reservations about changing the type of this, particularly
> that it will make refactoring from Inner Classes to Lambdas and vice
> versa error prone.

That's a risk, but (a) most of the time the compiler will catch simply cut and paste bugs and (b) we expect IDEs to provide "refactor lambda to named inner class" refactorings, which can adapt / warn on code that uses 'this'.  

> May I suggest a further couple of changes that
> might make refactoring more reliable:
> 
> 1. SAM types can only be interfaces (you must use an inner class if
> you want to inherit from and abstract class or class).

We explored this early on and concluded this was unsatisfactory.  It is quite common in the evolution of a project that interface-based SAM types evolve to be abstract classes when the need for "optional", rarely-used methods is encountered.  This conclusion was made on the basis of looking at specific code bases.  However, moving the cutoff just past "abstract classes with no-arg constructors" captures many more of the desirable cases and excludes relatively few.  

> 2. The specification defines what all Object's methods do for a
> Lambda, in particular getClass, toString, equals, and hashCode, and
> how instanceof behaves, is a Lambda an instance of MethodHandle is it
> an instance of its SAM type?

Neither.  Lambdas expressions can be *converted to* references to SAM types.  It is not specified what they are; they cannot exist in any context other than one in which they will be converted.  So you cannot assume they are objects, or SAM types, or anything.  

This turns out to be far less of a restriction than you might think.  (Think: what is the type of a method body?  Does it bother you that in all your years of Java coding, you've never had the need to ask this question?)