甚至有些人认为,尽早发布,频繁发布的频率应该更高。尽管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