译/马国耀 在一篇题为《重新思考JDK7》的博文(以及jdk7-dev的跨站转贴)中,Mark Reinhold提出了将先前计划在JDK7中实现的某些特性推迟到JDK8的建议,以期JDK7的早日面世。该建议是好是坏?在社区里引起了广泛的讨论。 当人们已经接受到JDK的推迟已经导致了早前声明的时间表的拖延(当然,这个时间表是无论如何也无法实现的)之后,目前讨论的焦点是是否要提前推出一个版本,还是等到万事俱备时才发布。Mark的建议是: 就目前我们对“B计划”的评估来看,我们可以在2011年中期发布简化版的JDK7,然后在2012年下半年发布JDK8。 颇具讽刺的是,Mark的博客的副标题是“刻不容缓!”。然而,从对该博文的回复看,好几个回帖都认为早发布、频繁发布比一次性发布好。虽然人们更期望B计划中的某些特性,而对另外一些则差一些,但是毫无疑问,B计划中的Coin项目将对Java语言带来极大的好处。Joseph D. Darcy对Coin的特性澄清如下:
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,对于这一改变,他只能苦中寻乐: 对我所做的工作而言,函数处理也许是即将到来的JDK7的最重要的特性之一。对于所有希望无需生成单个方法类就能描述函数或函数指针的JVM语言的人们而言,这无疑会成为关键的一部分(因为,当前所有的JVM语言必须要做这个工作,若不是在这里,就是在那里)。但是它们的推迟则意味这像JRuby这样的语言实现不得不依然要苦苦挣扎,构建前所未有的聪明的代码来生成策略才能躲过内存溢出(或避免吃掉过多的内存)。该特性发布的越早越好。 甚至有些人认为,尽早发布,频繁发布的频率应该更高。尽管Java 6的存在已经有一段时间了,其版本模式却隐藏了这段时间内VM上进行的一些重大改变。Osvaldo Pinali Doederlein写道: 主要原因当然是JDK6.1。我一直在跟随“后-6uN”的发布,在这些发布中Sun/Oracle不断地扩展Java 6的包裹,在不破坏其TCK的同时不断进行改进。我已经对6u23的第一次构建进行了测试,(除了一些Swing的补丁外)它还带来了另一重大的VM的更新,目前已抵达最尖端的HotSpot 19了(在当时看来是JDK7的最新技术)。它包括了JDK 7中如此尖端的特性,譬如,最新的G1收集器、对JSR-292完整的VM支持,以及其他诸如64 Gb堆的CompressedOops、CMS补丁和数千万的更小的虚拟机/运行时补丁以及改进。 推迟的另一好处是,这样就能正确地完成该做的事情,而不需要匆匆忙忙敷衍了事。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平台越大越好”。可是,更大意味着更多的内部依赖,而依赖来又快速地带来了平台的复杂度。绳索越多,死结也就越多。一次次推迟时间表就是一个征兆。 在这次简短的申明中,Oracle正在考虑将一些早前计划在JDK7中实现的某些特性推迟,因为它们将问题转变成政变。大量支持“尽早发布,频繁发布”的评论使得他们有勇气在JavaOne上正式宣布推迟的计划而且宣称社区是支持他们的。(如果他们单单在Lambda-Dev邮件列表中申明,他们收到的反对声音一定会多于支持的声音。)同时,这也给了Java平台一个希望,让它有更多的时间让一些不太完善的类(Lambda)变得成熟并且考虑一些东西是否必要(如 Jigsaw)。有一件事是肯定的:将问题公之于众,Oracle终于理解了社区意见的价值。 查看英文原文:JDK7 Feature Slip |
|