【发布时间】：2010-03-27 12:04:54
【问题描述】：
那么 Java 7 最终会获得闭包吗？最新消息是什么？
【问题讨论】：
-
@Ananthe Kumaran：这个问题是在一年前提出的。从那时起，许多事情都发生了变化。
-
@Anantha Kumaran：在 Java 闭包中一切都变了。和主要的变化 - 辩论已经结束，据说会增加关闭。
【发布时间】：2010-03-27 12:04:54
【问题描述】：
是的，Java 7 的发布计划包括关闭（这是将发布从冬季推迟到秋季的最重要原因（预计在 2010 年 9 月））。
最新消息可以在Project Lambda找到。您可能也有兴趣阅读latest specification draft。
【讨论】：
-
其实是因为其他原因需要延迟，额外的时间使得加闭包成为可能。
目前没有关于关闭状态的官方声明。
这里是 some readable examples 它的工作原理和外观。
如果您想深入了解正在发生的事情，我建议您联系OpenJDK mailing list。
概述
基本上还是有希望的，因为代码和一些测试已经提交到某个源代码分支，并且至少有一些中途工作的基础设施来测试它。
来自Maurizio Cimadamore 的更改消息如下：
初始 lambda 推送；当前原型支持以下特性：
- 函数类型语法（可选用 -XDallowFunctionTypes 启用）
- 函数类型子类型化
- 完全支持类型 1 和 2 的 lambda 表达式
- 推断 lambda 中的抛出类型/返回类型
- 使用 v0.1.5 草案中指定的规则进行 lambda 转换
- 支持对“this”的引用（显式和隐式）
- 使用方法句柄进行翻译
修改后的脚本构建 langtools 存储库现在生成一个 名为 javacrt.jar 的附加 jar 文件 其中包含一个助手类 在 SAM 转换期间使用；之后 build，生成的脚本 javac/java 会处理 自动设置所需的 依赖项，以便代码包含 lambda 表达式可以被编译和 执行。
但这是正在进行的工作，目前还存在很多问题。 例如，编译器有时会在有效表达式上崩溃，无法编译正确的闭包语法代码或生成非法字节码。
消极的一面是来自 Neal Gafter 的some statements：
从 0.15 草案到现在已经快三个月了，现在更少了 比 TL（工具和语言）最终集成前两周 前面的openjdk7功能齐全。如果您在以下方面取得了进展 规范和实现，我们将非常感谢它 与我们分享。如果没有，也许我们可以提供帮助。如果甲骨文已经决定 这个特性对 JDK7 来说不再重要了，这很高兴知道 也。无论发生什么，沉默都会发出错误的信息。
Neal Gafter 和 Jonathan Gibbons 之间的discussion：
很高兴看到这个，毛里齐奥！不幸的是，它来得太晚了一个星期，而且 在错误的存储库中，将被包含在 jdk7 中。
我注意到没有一个测试显示函数类型的变量是 转换为 SAM 类型。那里有什么计划？ 乔纳森·吉本斯的response： 由于 jdk7 发布的功能列表和发布的时间表 jdk7会出现矛盾，为什么你总是假设时间表 是正确的？ 尼尔·加夫特answer: 因为我记得反复讨论的大意是功能集 将根据它们的完成状态进行调整 时间表。
有些人甚至质疑整件事是否有意义，suggest moving to another language：
人们开始怀疑，为什么不直接迁移到 Scala —— 还有更多 需要添加到 Java 中以构建连贯的组合 围绕 lambdas 的特征。而现在这些延误，不仅影响 ParallelArray 的用户，但每个想要构建整齐重构的人， Java 中的可测试软件。
似乎没有人提议在 Java 中添加声明站点差异 => 表示
FunctionN<T, ...>接口不会按照应有的方式进行子类型化。 原语也没有专门化。 （Scala 的 @specialized 是 除了玩具类之外的所有东西都坏了，但至少它在向右移动 方向）没有 JVM 级别的识别对象是一个闭包，因此可以是 消除，因为它可以与 Scala 的闭包消除（如果 HOF 可以 也被内联。）JVM 似乎添加了一些类似于不可避免的机器的东西 对每个多态调用站点的词访问，即使它们被认为是 内联缓存而不是超态，即使在循环内也是如此。结果我已经 所见是玩具微基准测试的大约 2 倍减速，例如“对数组求和” 整数”如果用任何形式的闭包实现 可以在 Scala 中使用@inline。 （即使在 Scala 中，大多数 HOF 也是虚拟的 因此不能内联。）我希望看到可用的内联 /鼓励/在每个 for 循环中使用闭包的语言。
结论
这只是对正在发生的整个问题的快速浏览，引用和陈述根本不是详尽无遗的。目前人们还处于“Java 中真的可以实现闭包吗？如果可以，应该如何实现以及看起来如何？”的状态。
没有简单的“好吧，我们只是在周末为 Java 添加闭包”。 由于一些设计错误的相互作用，比如可变参数作为数组，类型擦除......有些情况是行不通的。找出所有这些小问题并确定它们是否可以解决是相当困难的。
最后，可能会有一些惊喜。 我不确定那个惊喜会是什么，但我猜它会是：
- 闭包不会进入 Java 7 或
- Java 7 中的闭包将与 Java 5 中的泛型一样（有缺陷、复杂的东西，看起来它可能会起作用，但一旦你进一步推动它就会崩溃）
个人意见
我很久以前就切换到了 Scala。只要 Oracle 不对 JVM 做傻事，我就不管了。在 Java 语言的进化过程中犯了错误，部分原因是向后兼容。这给人们试图做出的每一次新改变都带来了额外的负担。
基本上：Java 可以工作，但该语言将不再进化。人们所做的每一次改变都会增加进行下一次改变的成本，使未来的改变越来越不可能。 我不相信在 Java 7 之后 Java 语言会有任何变化，除了一些小的语法改进，比如项目 Coin。
【讨论】：
最新消息是截至 2009 年 11 月下旬的 AFAIK，闭包将以某种形式出现在 Java 7 中。由于这是发布显着延迟的主要原因，因此他们似乎不太可能再次放弃它。
【讨论】：
-
不，它没有被认为是发布显着延迟的主要原因。发布的显着延迟被认为是他们将尝试添加闭包的原因之一。
在 lambda-dev 邮件列表上进行了大量与语法和透明度相关的辩论（特别关注阅读具有特定语法的柯里化函数有多难），并且有一个来自 Sun 的几个提案迭代草案，但我已经有一段时间没有在该列表中看到他们的太多内容了。
【讨论】：
我现在正在参加一个发布会议，演讲者说 Java 8 即将关闭。
【讨论】：