@FunctionalInterface如何影响JVM的运行时行为？

我最初的问题是这个问题的完全重复; 也就是说，为什么这个接口有一个运行时保留策略。

但是接受的答案根本不能满足我，原因有两个：

这个接口是@Documented的事实（我相信）与它无关（尽管为什么@Documented有一个运行时保留策略对我来说也是一个谜）;
尽管在Java 8之前Java中存在许多“将是”function接口（ Comparable提及，但Runnable等），这并不妨碍它们被用作“替代品”（例如，你可以很好地使用它）一个DirectoryStream.Filter作为Predicate的替代，如果你所做的只是在Path上过滤，例如）。

但仍然有这种保留。这意味着它必须以某种方式影响JVM行为。怎么样？

我在core-libs-dev邮件列表中找到了该线程，该列表讨论了@FunctionalInterface注释的保留。这里提到的要点是允许第三方工具使用此信息进行代码分析/validation，并允许非Java JVM语言将其lambda正确映射到function接口。一些摘录：

Joe Darcy （ @FunctionalInterface原始提交者）：

我们故意使这个注释具有运行时保留，以便在运行时也可以查询各种工具等。

Brian Goetz

Java以外的语言有一个好处，可以使用它作为一种方法来确定接口是否适合传递给SAM转换机制。 JDK对lambda转换的支持也可用于其他语言。

所以似乎JVM本身并没有使用它，它只是第三方工具的另一种可能性。使注释运行时可见并不是一个很大的成本，所以似乎没有强有力的理由不这样做 。

具有保留策略运行时的注释的唯一要求是

注释将由编译器记录在类文件中，并在运行时由VM保留，因此可以reflection性地读取它们。（ https://docs.oracle.com/javase/7/docs/api/java/lang/annotation/RetentionPolicy.html#RUNTIME ）

现在这会对运行时行为产生一些影响，因为类加载器必须加载这些annoations，并且VM必须将这些注释保留在内存中以进行reflection访问（例如，通过第三方库）。

但是，不需要VM对这样的注释起作用。