【IT168 评论】在一篇题为《重新思考JDK7》的博文(以及jdk7-dev的跨站转贴)中，Mark Reinhold提出了将先前计划在JDK7中实现的某些特性推迟到JDK8的建议，以期JDK7的早日面世。该建议是好是坏?在社区里引起了广泛的讨论。
当人们已经接受到JDK的推迟已经导致了早前声明的时间表的拖延(当然，这个时间表是无论如何也无法实现的)之后，目前讨论的焦点是是否要提前推出一个版本，还是等到万事俱备时才发布。Mark的建议是：
就目前我们对“B计划”的评估来看，我们可以在2011年中期发布简化版的JDK7，然后在2012年下半年发布JDK8。
总结如下：
A计划：2012年中期发布JDK 7(按照目前的定义)
B计划：2011年中期发布JDK 7(除去Lamba、Jigsaw和Coin的一部分)
B计划：2012年后期发布JDK 8(Lambda、Jigsaw和剩下的Coin等)
颇具讽刺的是，Mark的博客的副标题是“刻不容缓!”。然而，从对该博文的回复看，好几个回帖都认为早发布、频繁发布比一次性发布好。虽然人们更期望B计划中的某些特性，而对另外一些则差一些，但是毫无疑问，B计划中的Coin项目将对Java语言带来极大的好处。Joseph D. Darcy对Coin的特性澄清如下：
二进制文字以及文字的下划线
switch语句中的字符串
<>操作附
异常处理的改进
简化varargs方法调用
面向资源的try语句
B计划还包含jsr166y类 (ForkJoin、TransferQueue、Phaser等)。此外，它还对JVM做了一些改进，如对动态调用的JSR292的支持将出现在JVM这一层。虽然对于静态类型的Java语言，它的用处似乎不大，但它可用来优化当前使用的Method.invoke()方法(当在RMI或其他企业服务器使用时)。如果这一特性还包含对MethodHandle的语言支持，那么在Java类中调用函数将方便很多，因为不再需要通过反射机制查找名称正确的消息(MethodHandle的底层使用invokedynamic，但需要更改JLS，所以B计划有可能包含invokedynamicVM指令和MethodHandle类，但不包含对文字的支持)。
在JVM上实现其他语言的人们应该为该时间表的更改感到兴奋，因为invokedynamic可用的日期更早了，他们不再需要等到2012年了。(不过，两个计划都将Lambda等放到了2012年)。对于同时工作在基于JVM的JRuby上的Mirah的Charles Nutter，对于这一改变，他只能苦中寻乐：
所以，我该不该心甘情愿地放弃Jigsaw、Lambda和Coin呢?Jigsaw和Coin也许还能，即便它们一定会(JDK7中)缺失。而对于Lambda而言……如果它不能在短期内完成实际函数类型、整合函数处理与动态调用，它就应该等到这一切都完备了才发布出来。这么说，我是很难过的，但是我们的确有JVM上的其他语言可以完成那个闭包(closure)，比如我自己的JRuby和Mirah(Mirah偶尔可以提供闭包[closure]甚至更多功能，而不需要任何运行时库或JVM的支持)。对我们而言，JVM的匿名内部类依然很棒(如果你看看JRuby的代码库……你会发现数以百计这样的应用)。
对了，对于鼓吹Scala的人……请解释一下Scala如何解决B计划中可能缺失的那些特性。没错，它有自己的闭包(closure)，但是它们不能与其他语言或正则Java代码进行互操作(除非你相应地限制你的设计)，这样一来，除了Scala程序员，它们对于其他人它就没什么用处了。它们没有完成Jigsaw目标的能力。而且，(我相信)Scala所提供的大部分Coin的特性都已经提供了。Scala不会成为Java语言作为JVM的替代品，永远不可能。
甚至有些人认为，尽早发布，频繁发布的频率应该更高。尽管Java 6的存在已经有一段时间了，其版本模式却隐藏了这段时间内VM上进行的一些重大改变。Osvaldo Pinali Doederlein写道：
版本数在一定程度上是一个比较随性的东西。Sun多次更改J2SE/JavaSE的版本模式，总是会引起世界上至少一半人的反对。有些人认为6u10应该称为6.1。以此类推，我重新做了如下命名：6u14->6.2, 6u18->6.3, 6u21->6.4 and 6u23->6.5。这样说我们可能会觉得好过一些：“好吧，JDK7又推迟了，见鬼去吧!……但至少我们还有6.5!”
推迟的另一好处是，这样就能正确地完成该做的事情，而不需要匆匆忙忙敷衍了事。Lambda项目和核心Java库中有些冲突的地方(例如，如何在短期内改造Collections类，以使之能利用Lambda的优势)，这种冲突在短期内可能会引起问题。通过为Lambda项目争取更多时间，就可在JDK8中解决这些问题，而不会耽误JDK7的发布。不单如此，最新的提案中全面删除了Java中的函数类型(早前在InfoQ中已经提到这事)。由于到有了更多的时间，曾经有人呼吁重新考虑这个决定。可是，首要问题是，删除它的原因尚不明确(类型系统的问题?亦或是时间的问题?)，它能否回来同样不明朗。
Jigsaw也是一样。Jigsaw是JDK在模块系统方面的一个尝试。虽然OSGi长期以来作为Java在模块系统方面的标准，但是Jigsaw试图从拆分JVM库和Java库的角度重新缔造轮子。Qwylt试图将二者统一，但是正如某些地方提到的，事实上，JVM和Java库的目标完全不同。从这个角度，从Java库中分离出JVM的C计划将是最好的。这样，诸如 IO、NIO、NNIO、NNNIO之类的库就能按照自己的步伐进行升级了，而不再需要依赖于JVM+Java库的综合版的每次更新了。
Peter Kriens写道：
模块化是让我们既能拥有蛋糕，又能吃蛋糕的唯一的机制。如果Java包括一个核心的Java平台，那么我们就能轻易地以独立模块的形式加入JSR的实现。如果我从不使用Swing，我的平台为什么要包含它呢?也许在另一个版本中我可能会使用它。将JSR模块化可能会让小应用变得复杂，但是，在任何实际的应用中，处理外部依赖的工作已经成为繁杂生活的一部分了。其复杂的原因在于，Java无论如何也不能解决某些依赖。
我们所需的是一个最小的、能真正理解模块的核心平台。这个最小的Java不再把所有的Javax包打在一起，而只应该包含良好地定义的核心包和一个能够正确处理来自(远程)存储库的机制，该机制保证了向桌面应用和服务器增加新库的任务变得简单。Perl能做到、Ruby能做到、Python也可以做到，为何Java做起来就那么艰难呢?还是兑现承诺，做得更好一点儿吧。
我们的确拥有技术，所有部件都在那儿。Oracle，这次推迟是一个好机遇，我们能让Java再一次敏捷起来吗?
在这次简短的申明中，Oracle正在考虑将一些早前计划在JDK7中实现的某些特性推迟，因为它们将问题转变成政变。大量支持“尽早发布，频繁发布”的评论使得他们有勇气在JavaOne上正式宣布推迟的计划而且宣称社区是支持他们的。(如果他们单单在Lambda-Dev邮件列表中申明，他们收到的反对声音一定会多于支持的声音。)同时，这也给了Java平台一个希望，让它有更多的时间让一些不太完善的类(Lambda)变得成熟并且考虑一些东西是否必要(如 Jigsaw)。有一件事是肯定的：将问题公之于众，Oracle终于理解了社区意见的价值。
查看英文原文：JDK7 Feature Slip
