java - 为什么Java中的@FunctionalInterface没有@ConformsTo？

Question

Java (1.8+) 有一个 @FunctionalInterface 注释，它(基本上)建议您可以将方法引用代替接口(interface)实现传递给另一个方法调用。我今天玩的有用的是:

DateTimeFormatter.parse(String, TemporalQuery<T>)

这很好，因为它可以让您告诉格式化程序将什么样的结果返回给您。 javadoc 甚至给了你一个很好的例子:

The query is typically a method reference to a from(TemporalAccessor) method. For example: 
  LocalDateTime dt = parser.parse(str, LocalDateTime::from);

一旦我了解了 @FunctionalInterface 的含义和含义，我就开始想知道 API 的使用者如何确定他们实际上可以使用什么来代替它。上面的例子告诉你可以使用什么，如果你跟踪java.time包，你可以找到其他可以使用的方法引用。然而，API 的任何贡献者都需要通读整个 javadoc，以确保他们不会破坏其他地方提到的任何隐式契约(当然他们应该这样做，特别是对于 JDK，但这不是 javadoc 的目的!)

所以..如果此 API 的贡献者要更改 LocalDateTime::from 的签名，则不会进行编译时检查来表明此方法不再符合“TemporalQuery”的 FuncitonalInterface。这显然会破坏 API 的任何使用者，他们可以更改代码以使用显式 lambda。我确实知道它不需要，但是如果类似于可选的“@Override”注释的注释可用，那么它将提供一些编译时检查以及内省(introspection)/反射(reflection)以发现可用方法引用的可能性。

例如

@ConformsTo(TemporalQuery.class)
public static LocalDateTime from(TemporalAccessor temporal)

然后还可以通过内省(introspection)找到可用于FunctionalInterface的任何其他方法引用。

因此，需要明确的是，我知道这是没有必要的，但确实认为不将其作为可选注释包含在内似乎是一个疏忽。有什么特殊原因可以/不应该存在吗？

Answer 1

因更改方法的签名或返回类型而产生的问题，例如LocalDateTime::from 不限于函数式接口(interface)。即使在 Java 8 之前，更改这些内容也存在破坏依赖这些内容的现有代码的风险。这就是为什么设计 API 始终是一个挑战，因为对现有代码的更改可能意味着大量工作。

此外，假设功能接口(interface)和匹配方法是不同库的一部分，您是否真的希望它们紧密耦合，即当其中一个发生更改时，两者都需要更改？如果它们由不同的组织(比如说不同的开源项目或公司)维护怎么办 - 他们应该如何协调？

以 Comparator.comparing(Function<? super T, ? extends U> keyExtractor) 为例。这基本上接受对任何不带参数并返回可比较内容的方法的引用。有很多库已经提供了这些方法，您是否希望它们都必须添加 @ConformsTo ？

也就是说，一个 @ConformsTo充其量是不完整的，甚至可能具有误导性/过时的。

编辑:

让我们从编译器的角度来处理这两个注释。

@FunctionalInterface告诉编译器，当您定义多个抽象方法或在接口(interface)以外的其他东西上使用它时，它应该提示。

这意味着需求/契约定义(“此接口(interface)是一个功能接口(interface)”)和实现(接口(interface)本身)包含在同一个文件中，因此无论如何都必须一起更改。

@ConformsTo可以告诉编译器检查函数接口(interface)(甚至接口(interface))的要求，看看该方法是否满足它们。

到目前为止一切顺利，但是当接口(interface)更改时就会出现问题:它将方法和接口(interface)耦合在一起，而方法和接口(interface)可能属于不同的且完全不相关的库的一部分。即使它们是同一个库的一部分，当方法本身不会重新编译时，您也可能会遇到问题 - 编译器可能会错过这种不兼容性，从而违背该注释的目的(如果它仅适用于人类，那么一个简单的评论也足够了)。