java - Scala 闭包和 Java 8 闭包之间的兼容性

Question

在阅读了一些 OpenJDK 邮件列表条目后，似乎 Oracle 开发人员目前正在进一步从闭包提案中删除一些内容，因为 Java 语言中早期的设计错误使 Java 闭包的引入变得复杂。

考虑到 Scala 闭包比为 Java 8 计划的闭包强大得多，我想知道是否可以 e. G。调用一个从 Scala 获取闭包的 Java 方法，在 Java 中定义一个闭包并将其提供给 Scala 函数等？

那么 Java 闭包会像 Scala 对应的字节码一样表示还是以不同的方式表示？是否有可能缩小 Java/Scala 闭包之间的功能差距？

Answer 1

我认为这比假设这里有两组利益相关者要复杂得多。 Project Lambda人们似乎大多独立于 Oracle 人员工作，occasionally throwing something over the wall Project Lambda 的人间接地发现了这一点。 (Scala，当然是第三个利益相关者。)

自从latest Project Lambda proposal是一起消除函数类型，并为实现具有单个抽象方法(SAM类型)的接口(interface)创建某种花哨的推理，我预见到以下内容:

• 调用需要 Scala 闭包的 Scala 代码将完全取决于 Function* 特征的实现(以及一般特征的实现)——它是否出现在 Java 编译器中作为 SAM(它在 Scala 领域)，或者非抽象方法对 JVM 是否也显得抽象。 (我认为它们目前看起来确实是抽象的，因为特征是作为接口(interface)实现的，但我对 Scala 的实现几乎一无所知。这可能是互操作性的一大障碍。)

  Java泛型的复杂性(特别是如何表达Int/int/Integer，或Unit/Nothing/void in a generic interface)也可能使事情复杂化。

• 使用 Scala 函数来实现 Java SAM 与现在没有什么不同——您需要为您希望实现的特定接口(interface)创建一个 implicit 转换。

如果 JVM 获得函数类型(而 Oracle 似乎没有消除这种可能性)，它可能取决于它是如何实现的。如果它们是实现特定接口(interface)的第一类对象，那么为了兼容，Scala 需要做的就是让 Function* 实现新接口(interface)。如果一种新的类型完全在 JVM 中实现，那么这可能会很困难——Scala 开发人员可能会像现在对 Array 那样使用魔法来包装它们，或者他们可能会创建创建 隐式转换。 (一个新的语言概念似乎有点牵强。)

我希望所有这些讨论的结果之一是所有各种 JVM 语言都将就表示闭包的一些标准方式达成一致——以便 Scala、Groovy、JRuby 等... 都可以以最少的麻烦来回传递闭包。

我更感兴趣的是 virtual extension methods 的提案。这将允许 Java Collections API 使用 lambdas。根据它们的实现方式，它们可能会极大地简化我们在更改 Scala 代码时必须处理的一些二进制兼容性问题，并且它们可能有助于更轻松、更有效地实现特征。

我希望一些 Scala 开发人员参与进来并提供他们的意见，但我实际上并没有在 Project Lambda 列表中看到任何关于 Scala 的讨论，也没有任何参与者以 Scala 开发人员身份跳出来告诉我。