问题标签 [jsr335]

据说 JSR-335 很快就会与 Java 8 一起出现。它带来了对闭包和虚拟扩展方法的支持。我想知道在 JVM 级别上是否对此有任何特别的支持？如果是这样，我们是否希望在基于 JVM 的函数式语言中提高速度，这些函数式语言提供闭包和类似扩展方法的特性（例如 scala 中的特征或隐式）？

编辑：阅读Brian Goetz关于 Java 8 的 Oracle 演示文稿，看起来： - 不需要闭包 - 虚拟扩展方法确实需要特定的 JVM 支持。

这是否意味着在 scala 中，一些隐含和特征可以以更有效的方式重新实现？

在当前的 JSR 335 草案中，在0.6.0的更改日志条目中提到它“消除了对未绑定内部类构造函数引用的支持”。

为了说明，假设您有一个名为 的外部类A和一​​个名为 的内部类B，并且您想要一个接受A并创建一个新B实例的函数：

在 0.6.0 之前，您还可以使用构造函数引用语法来做同样的事情（它甚至记录在State of the Lambda 中）：

如上所述，0.6.0 不再支持该语法。我真的很想知道为什么。

我已经查看了邮件列表lambda-spec-experts和lambda-dev邮件列表的档案，但找不到任何有关它的信息。

Java 8 最有用的特性之一是default接口上的新方法。引入它们的原因基本上有两个（可能还有其他原因）：

• 提供实际的默认实现。例子：Iterator.remove()
• 允许 JDK API 进化。例子：Iterable.forEach()

从 API 设计者的角度来看，我希望能够在接口方法上使用其他修饰符，例如final. 这在添加便捷方法时很有用，可以防止实现类中的“意外”覆盖：

Sender如果是一个类，以上已经是常见的做法：

现在，defaultandfinal显然是矛盾的关键字，但 default 关键字本身并不是严格要求的，所以我假设这种矛盾是故意的，以反映“带主体的类方法”（只是方法）和“接口”之间的细微差别带有主体的方法”（默认方法），即我尚未理解的差异。

在某些时候，还没有完全探索对接口方法等修饰符的支持，static引用Brian Goetz的话：final

另一部分是我们将在接口中支持类构建工具的程度，例如最终方法，私有方法，受保护方法，静态方法等。答案是：我们还不知道

自 2011 年底以来，显然static增加了对接口方法的支持。显然，这为 JDK 库本身增加了很多价值，例如Comparator.comparing().

问题：

是什么原因final（也是static final）从未进入 Java 8 接口？

在 Java 8 中，我可以轻松编写：

我将获得我也可以在类中使用的完整同步语义。但是，我不能synchronized在方法声明中使用修饰符：

现在，人们可以争辩说，这两个接口的行为方式相同，只是在 on和 on 上Interface2建立了一个合同，这比什么强一点。当然，我们也可能会争辩说，实现不应该对具体的实现状态做出任何假设，或者这样的关键字根本不会发挥作用。method1()method2()Interface1default

问题：

JSR-335 专家组决定不支持synchronized接口方法的原因是什么？