譯/馬國耀

　　在一篇題為《重新思考JDK7》的博文（以及jdk7-dev的跨站轉(zhuǎn)貼）中,，Mark Reinhold提出了將先前計劃在JDK7中實(shí)現(xiàn)的某些特性推遲到JDK8的建議，以期JDK7的早日面世,。該建議是好是壞,？在社區(qū)里引起了廣泛的討論。

　　當(dāng)人們已經(jīng)接受到JDK的推遲已經(jīng)導(dǎo)致了早前聲明的時間表的拖延（當(dāng)然,，這個時間表是無論如何也無法實(shí)現(xiàn)的）之后,，目前討論的焦點(diǎn)是是否要提前推出一個版本，還是等到萬事俱備時才發(fā)布,。Mark的建議是：

就目前我們對“B計劃”的評估來看,，我們可以在2011年中期發(fā)布簡化版的JDK7，然后在2012年下半年發(fā)布JDK8,。

總結(jié)如下：

• A計劃：2012年中期發(fā)布JDK 7（按照目前的定義）
• B計劃：2011年中期發(fā)布JDK 7（除去Lamba,、Jigsaw和Coin的一部分）
• B計劃：2012年后期發(fā)布JDK 8（Lambda、Jigsaw和剩下的Coin等）

　　頗具諷刺的是,，Mark的博客的副標(biāo)題是“刻不容緩,！”。然而,，從對該博文的回復(fù)看,，好幾個回帖都認(rèn)為早發(fā)布、頻繁發(fā)布比一次性發(fā)布好,。雖然人們更期望B計劃中的某些特性,，而對另外一些則差一些，但是毫無疑問,，B計劃中的Coin項(xiàng)目將對Java語言帶來極大的好處,。Joseph D. Darcy對Coin的特性澄清如下：

• 二進(jìn)制文字以及文字的下劃線
• switch語句中的字符串
• <>操作附
• 異常處理的改進(jìn)
• 簡化varargs方法調(diào)用
• 面向資源的try語句

　　B計劃還包含jsr166y類 （ForkJoin、TransferQueue、Phaser等）,。此外,，它還對JVM做了一些改進(jìn)，如對動態(tài)調(diào)用的JSR292的支持將出現(xiàn)在JVM這一層,。雖然對于靜態(tài)類型的Java語言,，它的用處似乎不大，但它可用來優(yōu)化當(dāng)前使用的Method.invoke()方法（當(dāng)在RMI或其他企業(yè)服務(wù)器使用時）,。如果這一特性還包含對MethodHandle的語言支持,，那么在Java類中調(diào)用函數(shù)將方便很多，因?yàn)椴辉傩枰ㄟ^反射機(jī)制查找名稱正確的消息（MethodHandle的底層使用invokedynamic,，但需要更改JLS，所以B計劃有可能包含invokedynamicVM指令和MethodHandle類,，但不包含對文字的支持）,。

　　在JVM上實(shí)現(xiàn)其他語言的人們應(yīng)該為該時間表的更改感到興奮，因?yàn)閕nvokedynamic可用的日期更早了,，他們不再需要等到2012年了,。（不過，兩個計劃都將Lambda等放到了2012年）,。對于同時工作在基于JVM的JRuby上的Mirah的Charles Nutter,，對于這一改變，他只能苦中尋樂：

對我所做的工作而言,，函數(shù)處理也許是即將到來的JDK7的最重要的特性之一,。對于所有希望無需生成單個方法類就能描述函數(shù)或函數(shù)指針的JVM語言的人們而言，這無疑會成為關(guān)鍵的一部分（因?yàn)?，?dāng)前所有的JVM語言必須要做這個工作,，若不是在這里，就是在那里）,。但是它們的推遲則意味這像JRuby這樣的語言實(shí)現(xiàn)不得不依然要苦苦掙扎,，構(gòu)建前所未有的聰明的代碼來生成策略才能躲過內(nèi)存溢出（或避免吃掉過多的內(nèi)存）。該特性發(fā)布的越早越好,。

所以,，我該不該心甘情愿地放棄Jigsaw、Lambda和Coin呢,？Jigsaw和Coin也許還能,，即便它們一定會（JDK7中）缺失。而對于Lambda而言……如果它不能在短期內(nèi)完成實(shí)際函數(shù)類型,、整合函數(shù)處理與動態(tài)調(diào)用,，它就應(yīng)該等到這一切都完備了才發(fā)布出來。這么說,，我是很難過的,，但是我們的確有JVM上的其他語言可以完成那個閉包（closure）,，比如我自己的JRuby和Mirah（Mirah偶爾可以提供閉包[closure]甚至更多功能，而不需要任何運(yùn)行時庫或JVM的支持）,。對我們而言,，JVM的匿名內(nèi)部類依然很棒（如果你看看JRuby的代碼庫……你會發(fā)現(xiàn)數(shù)以百計這樣的應(yīng)用）。

對了,，對于鼓吹Scala的人……請解釋一下Scala如何解決B計劃中可能缺失的那些特性,。沒錯，它有自己的閉包（closure）,，但是它們不能與其他語言或正則Java代碼進(jìn)行互操作（除非你相應(yīng)地限制你的設(shè)計）,，這樣一來，除了Scala程序員,，它們對于其他人它就沒什么用處了,。它們沒有完成Jigsaw目標(biāo)的能力。而且,，（我相信）Scala所提供的大部分Coin的特性都已經(jīng)提供了,。Scala不會成為Java語言作為JVM的替代品，永遠(yuǎn)不可能,。

　　甚至有些人認(rèn)為,，盡早發(fā)布，頻繁發(fā)布的頻率應(yīng)該更高,。盡管Java 6的存在已經(jīng)有一段時間了,，其版本模式卻隱藏了這段時間內(nèi)VM上進(jìn)行的一些重大改變。Osvaldo Pinali Doederlein寫道：

主要原因當(dāng)然是JDK6.1,。我一直在跟隨“后-6uN”的發(fā)布,，在這些發(fā)布中Sun/Oracle不斷地擴(kuò)展Java 6的包裹，在不破壞其TCK的同時不斷進(jìn)行改進(jìn),。我已經(jīng)對6u23的第一次構(gòu)建進(jìn)行了測試,，（除了一些Swing的補(bǔ)丁外）它還帶來了另一重大的VM的更新，目前已抵達(dá)最尖端的HotSpot 19了（在當(dāng)時看來是JDK7的最新技術(shù)）,。它包括了JDK 7中如此尖端的特性,，譬如，最新的G1收集器,、對JSR-292完整的VM支持,，以及其他諸如64 Gb堆的CompressedOops、CMS補(bǔ)丁和數(shù)千萬的更小的虛擬機(jī)/運(yùn)行時補(bǔ)丁以及改進(jìn),。

版本數(shù)在一定程度上是一個比較隨性的東西,。Sun多次更改J2SE/JavaSE的版本模式，總是會引起世界上至少一半人的反對。有些人認(rèn)為6u10應(yīng)該稱為6.1,。以此類推,，我重新做了如下命名：6u14->6.2, 6u18->6.3, 6u21->6.4 and 6u23->6.5。這樣說我們可能會覺得好過一些：“好吧,，JDK7又推遲了,，見鬼去吧！……但至少我們還有6.5!”

　　推遲的另一好處是,，這樣就能正確地完成該做的事情,，而不需要匆匆忙忙敷衍了事。Lambda項(xiàng)目和核心Java庫中有些沖突的地方（例如,，如何在短期內(nèi)改造Collections類,，以使之能利用Lambda的優(yōu)勢），這種沖突在短期內(nèi)可能會引起問題,。通過為Lambda項(xiàng)目爭取更多時間,，就可在JDK8中解決這些問題，而不會耽誤JDK7的發(fā)布,。不單如此，最新的提案中全面刪除了Java中的函數(shù)類型（早前在InfoQ中已經(jīng)提到這事）,。由于到有了更多的時間,，曾經(jīng)有人呼吁重新考慮這個決定?？墒?，首要問題是，刪除它的原因尚不明確（類型系統(tǒng)的問題,？亦或是時間的問題?）,，它能否回來同樣不明朗。

　　Jigsaw也是一樣,。Jigsaw是JDK在模塊系統(tǒng)方面的一個嘗試,。雖然OSGi長期以來作為Java在模塊系統(tǒng)方面的標(biāo)準(zhǔn)，但是Jigsaw試圖從拆分JVM庫和Java庫的角度重新締造輪子,。Qwylt試圖將二者統(tǒng)一,，但是正如某些地方提到的，事實(shí)上,，JVM和Java庫的目標(biāo)完全不同,。從這個角度，從Java庫中分離出JVM的C計劃將是最好的,。這樣,，諸如 IO、NIO、NNIO,、NNNIO之類的庫就能按照自己的步伐進(jìn)行升級了,，而不再需要依賴于JVM+Java庫的綜合版的每次更新了。

　　Peter Kriens寫道：

Java正在遭到一個錯誤的觀念的緩慢破壞——“Java平臺越大越好”,?？墒牵笠馕吨嗟膬?nèi)部依賴,，而依賴來又快速地帶來了平臺的復(fù)雜度,。繩索越多，死結(jié)也就越多,。一次次推遲時間表就是一個征兆,。

模塊化是讓我們既能擁有蛋糕，又能吃蛋糕的唯一的機(jī)制,。如果Java包括一個核心的Java平臺,，那么我們就能輕易地以獨(dú)立模塊的形式加入JSR的實(shí)現(xiàn)。如果我從不使用Swing,，我的平臺為什么要包含它呢,？也許在另一個版本中我可能會使用它。將JSR模塊化可能會讓小應(yīng)用變得復(fù)雜,，但是,，在任何實(shí)際的應(yīng)用中，處理外部依賴的工作已經(jīng)成為繁雜生活的一部分了,。其復(fù)雜的原因在于,，Java無論如何也不能解決某些依賴。

我們所需的是一個最小的,、能真正理解模塊的核心平臺,。這個最小的Java不再把所有的Javax包打在一起，而只應(yīng)該包含良好地定義的核心包和一個能夠正確處理來自（遠(yuǎn)程）存儲庫的機(jī)制,，該機(jī)制保證了向桌面應(yīng)用和服務(wù)器增加新庫的任務(wù)變得簡單,。Perl能做到、Ruby能做到,、Python也可以做到,，為何Java做起來就那么艱難呢？還是兌現(xiàn)承諾,，做得更好一點(diǎn)兒吧,。

我們的確擁有技術(shù)，所有部件都在那兒,。Oracle,，這次推遲是一個好機(jī)遇,，我們能讓Java再一次敏捷起來嗎？

　　在這次簡短的申明中,，Oracle正在考慮將一些早前計劃在JDK7中實(shí)現(xiàn)的某些特性推遲,，因?yàn)樗鼈儗栴}轉(zhuǎn)變成政變。大量支持“盡早發(fā)布,，頻繁發(fā)布”的評論使得他們有勇氣在JavaOne上正式宣布推遲的計劃而且宣稱社區(qū)是支持他們的,。（如果他們單單在Lambda-Dev郵件列表中申明，他們收到的反對聲音一定會多于支持的聲音,。）同時,，這也給了Java平臺一個希望，讓它有更多的時間讓一些不太完善的類（Lambda）變得成熟并且考慮一些東西是否必要（如 Jigsaw）,。有一件事是肯定的：將問題公之于眾,，Oracle終于理解了社區(qū)意見的價值。

　　查看英文原文：JDK7 Feature Slip