Defining the Set of FunctionalInterfaces

[Gernot Neppert]

In the thread "what do we call the distinguished method of a SAM", I
uttered my concern that @FunctionalInterface would somehow be used to
discourage programmers from using the concise lambda-syntax for anything
else than Stream-related 'functional programming'.

Thankfully, Brian put this concern to rest in his response!

So now I'm trying to apply my newly-acquired knowledge about the true
spirit of the @FunctionalInterface annotation to the latest snapshot of the
JDK repo.

Some discussion points:

1. The only 'Listener-style' class annotated with @FunctionalInterface are
java.util.prefs.PreferenceChangeListener and
Thread.UncaughtExceptionHandler.
I tend to think that all single-method Listener interface match the
intention of a functional interface, an obvious example being
java.beans.PropertyChangeListener and many of the java.awt EventListeners.

2. java.util.Comparable is annotated with @FunctionalInterface.
This seems wrong to me. While technically being a functional interface, it
cannot be used a a stateless function. Rather, it always has to be
implemented by data-bearing classes.
I cannot think of a reason to encourage conversion of lambda expressions to
stand-alone java.util.Comparables.

3. java.io.Closeable is annotated with @FunctionalInterface.This is similar
to java.util.Comparable:
Stateful classes usually implement java.util.Closeable as a 'trait'.
Stand-alone Closeables created from lambda expressions will be extremly
rare.

4. java.util.concurrent.Callable is not annotated with
@FunctionalInterface, even though it is certainly being used as a function.