Bikeshed: what do we call the distinguished method of a SAM?

[Gernot Neppert]

2013/7/2 Brian Goetz <brian.goetz at oracle.com>

> How about:
>
> where this is defined in package info:
>
>  * <em>Functional interfaces</em> provide target types for lambda
> expressions
>  * and method references.  Each functional interface has a single abstract
> method,
>  * called the <em>functional abstract method</em> for that functional
> interface,
>  * to which the lambda expression's parameter and return types are matched
> or
>  * adapted.  Functional interfaces can provide a target type in multiple
> contexts,
>  * such as assignment context, method invocation, or cast context:
>
>
Hmm, until now I had accepted the introduction of the
'@FunctionalInterface' as something that mysteriously mattered to you
'Functional Experts', but that was equally gratuitous and harmless ;-)

But now, I'm getting worried. Is the language spec being changed again?
Will only Functional interfaces be allowed as the target types for
lambda-conversions?

Why do you explicitly stress that '...Functional interfaces provide target
types for lambda expressions and method references'?

Why do you seeminlgy restrict lambda conversions by stating that
'...Functional interfaces can provide a target type in multiple contexts,
such as assignment context, method invocation, or cast context'?

Are Java programmers discouraged to use lambda expressions in places that
expect java.lang.Runnables or java.awt.event.ActionListeners?

If so, that would be a shame. If not, this entire distinction between
'Functional' and non-functional SAMs looks totally deliberate to me!