为什么@FunctionalInterface没有用在JDK中所有符合条件的接口上？

Question

Java8为我们提供了许多有趣的方法来使用函数接口，并与它们一起使用了一个新的注释:@functionalinterface。它的工作是告诉编译器，如果我们没有遵守函数接口的规则（只有一个需要重写的抽象方法），就对我们大喊大叫。

java.util.function包中有43个带有这个注释的接口。在JDK.1.8.0/src中搜索@functionalinterface只有57次点击。为什么其他可以添加@functionalinterface的接口（如AutoCloseable）仍然缺少它？

注释文档中有一点模糊的提示：

向任何已发布的接口添加抽象方法难道不会使任何实现它的人陷入困境吗，不管是函数性的还是非函数性的？我觉得很愤世嫉俗，假设他们没有费心去追捕他们，但还有什么别的解释呢？

更新：翻看“‘可比’应该是一个‘功能接口’吗？”我发现我还有一些唠叨的问题。当一个方法接口和一个函数接口在结构上相同时，还有什么不同呢？区别仅仅是名字吗？Comparable和Comparator在语义上非常接近于同一。结果发现它们在结构上是不同的，但仍然不是最好的例子...

是否存在这样的情况：SMI在结构上很好地用作功能接口，但在接口和方法名称的语义意义上仍然不受欢迎？或者JavaDocs隐含的契约？

Answer 1

那么，如果您假设总是给定意图，那么记录意图的注释将是无用的。

您将示例命名为autocloseable，这显然不是要作为函数实现的，因为有runnable，这对于具有()->void签名的函数来说要方便得多。目的是让实现autocloseable的类管理外部资源，而通过lambda表达式实现的匿名类不这样做。

一个更清楚的例子是comparable，interface不仅不打算作为lambda表达式实现，而且不可能使用lambda表达式正确地实现它。

>

接口具有编程语言语义，例如自动关闭或可迭代（您自己的接口不太可能发生这种情况）

不希望接口具有任意实现和/或更多地是实际实现的标识符，例如java.net.protocolfamily或java.lang.Reflect.GenericArrayType（请注意，后者还将继承GetTypeName()的Default实现，因为它依赖于ToString())对于lambda实现是无用的）

此接口的实例应具有标识，例如java.net.protocolfamily、java.nio.file.WatchEvent.Modifier等。请注意，这些通常由枚举实现

另一个例子是java.time.chrono.era，它碰巧只有一个abstract方法，但它的规范说“可以使用==运算符比较era的实例。”

库维护器有一个包含200多个候选类型的大型代码库，而不是为每个接口讨论是否应该对其进行注释的资源，因此将重点放在在函数上下文中使用的主要候选类型上。我确信，例如java.io.objectinputvalidation、java.lang.reflect.invocationhandler、jucrejectedexecutionhandler&ThreadFactory作为@functionalinterface并不差，但我不知道例如java.security.spec.ecfield是否是一个好的候选。库越通用，库的用户就越有可能回答他们感兴趣的特定接口的问题，但坚持要求库维护人员回答所有接口的问题是不公平的。

在此上下文中，将@functionalinterface的存在看作是一条消息，表明interface肯定是要与lambda表达式一起使用的，而不是将注释的不存在看作不是要以这种方式使用的指示符，这更有意义。这与编译器处理它的方式完全相同，您可以使用lambda表达式实现每个抽象方法接口，但当注释出现时，它将确保您可以以这种方式使用此接口。