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

Question

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

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

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

Answer 1

注意:5年后，SCALA 2.12.0-M3 (Oct. 2015)确实包含了这个增强功能：

JavaJavaScala2.12以与

8相同的方式发出闭包。

对于每个lambda，编译器生成一个包含lambda主体的方法。

在运行时，此方法作为参数传递给JDK提供的LambdaMetaFactory，后者创建一个闭包对象。

与Scala2.11相比，新方案的优点是编译器不再为每个lambda生成匿名类。这会导致JAR文件明显变小。

Answer 2

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

由于latest Project Lambda proposal将一起消除函数类型，并为实现具有单个astract方法(SAM类型)的接口创建某种花哨的推理，因此我预计会出现以下情况：

Java调用需要闭包的Scala代码将完全依赖于Function*特征的实现(以及一般的特征实现) --它对

• 编译器来说是作为一个Function*(它在Scala -land中)出现，还是非抽象方法对Java虚拟机来说也是抽象的。(我认为它们目前看起来确实很抽象，因为特征是作为接口实现的，但我对Scala的实现几乎一无所知。这可能是互操作性的一个很大的障碍。)

Java泛型的复杂性(特别是如何在泛型接口中实现expressInt/int/Integer，或Unit/Nothing/void )也可能使实现Java的things.

• Using Scala函数复杂化--您需要为您希望实现的特定接口创建implicit转换。

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

我希望所有这些讨论的结果之一是，所有不同的JVM虚拟机语言都会在表示闭包的标准方式上达成一致--因此Scala、Groovy、JRuby等……所有的闭包都可以在最小的麻烦中来回传递。

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

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

Answer 3

您可能能够非常容易地使用隐式转换a la collection.JavaConversions来实现这一点，无论它们是否开箱即用。

当然，事实并非如此，因为Java闭包可能会被转换为JVM在运行时生成的类型-我似乎记得Neal Gafter演示文稿中说过这样的话