---待到Java 8面世之時 .Net的進度時鐘恐怕已經又走過了兩到五年——屆時微軟做出的調整將使二者差距進一步拉大。

就在幾周之前，我詳細介紹了Java 8中值得期待的幾大主要功能。不過當時我并沒有提到.Net的新變化，事實上Java 8中的大部分（甚至全部）功能都能在.Net中找到。更夸張的是，不少將被推遲到Java 9中實現的功能也將在.Net中出現。我并不贊成將一切功能盲目塞進Java語言的激進行為，不過我認為Java平臺（相對于語言本身）確實應該在功能多樣性方面下點功夫。在我看來，.Net技術堪稱杰出，C#與.Net平臺自Java 3時代就開始在各個方面迎頭趕上。就個人而言，我對微軟的操作系統非常抵觸，而且很擔心無法修復討厭的bug（至少在理論上不行）。

兩套平臺、一個故事

很多朋友認為微軟公司在提供較小安裝基礎與激發開發者擁護熱情方面行動更快，這樣的論斷還算公正。我還記得上世紀九十年代與兩千年初時，微軟公司決定以幾乎每周一次的速度變更數據庫API，于是ODBC、RDO、ADO乃至OLEDB等等一下子涌到我們面前。然而隨著.Net的出現，微軟的研發強度達到了臨界值，后續而來的是更兇猛、更頻繁的發展進程。

然而Java為什么會落后如此之多？在Java出現的早期，其發展速度同樣令人贊嘆。從Java 1.0.2到Java 1.1，我們僅在一年之間就迎來了眾多根本性（通常也意味著存在兼容性問題）改變。其后，從1.1版本到1.2版本用了一年半時間，之后的1.22——一個看似小更新、實為大升級的版本——僅在七個月后就火熱出爐。短短十個月后，里程碑式的Java 1.3版本整裝待發，這也是第一個考慮在服務器端加入垃圾收集功能的版本。

Java 1.4給我們帶來了NIO（即網絡接口對象）與正則表達式，與前代版本相隔不到兩年。Java 1.4.2則在多核環境中實現了垃圾收集功能（雖然還不太穩定），開發周期為一年。接下來是Java 1.5，這個開發周期超過一年的新版本將并發一致性GC引入生產流程，并且加入了其它一些重要的并發及NIO功能。

Java 1.6將關注重點放在性能節約方面，雖然效果還算顯著，但其改進幅度仍然無法與1.5版本相提并論、更遑論用去了無數開發者兩年的等待時間。Java 1.7是自1.4.2以來第一個針對底層虛擬機技術（G1 collector）做出大幅改動的新版本，利用invokedynamic指令幫助我們在JVM環境下更好地與其它語言對接。盡管屬于大版本升級，但五年的更新周期無疑標志著Java的迭代步伐已經明顯放緩。

Sample features in Java and .Net and their release dates

進展為何如何緩慢？

我們可以這樣來簡單解釋Java的逐漸落后：Sun本來就不是一家運轉狀況良好的企業。Java誕生之初互聯網正迅速興起，Sun公司也將運營重點放在了銷售Sparc及相關產品方面。與此同時，英特爾與AMD產品的價格逐步下降，Sparc的價格卻未作調整。盡管T1000及之后平臺的陸續出現令人興奮不已，但卻始終未能形成規模經濟、從而將成本縮減到理想范圍（沒錯，最后一款Sparc執行效率更高，但價格卻貴得離譜；盡管政府當局要求能耗過高的用戶為碳排放過量狀況付費，但即便如此最終的總體成本也遠低于Sparc給數據中心帶來的硬件支出）。

互聯網經濟的泡沫最終煙消云散，Sun公司決定將手中已經建成的大型設備集群轉化為“商業化”計算硬件業務。總而言之，Sun在硬件業務方面押下了錯誤的賭注。

Sun所創造出的生態系統堪稱偉大，他們只是未能建立起真正符合企業需求、能夠激發用戶購買欲望的產品。作為Sun成果的最終持有者，甲骨文充分燃盡了生態系統中的每一分潛力，蠶食或者毀滅掉與之相關的一切其它企業，從而創造出僅屬于自己的高利潤替代產品。

甲骨文在一份典型的簡要公開聲明中，承認某些業務及政治問題拖延了Java 7的發布進度。“眾所周知，由于各種業務及政治問題的影響，最新版本的推出被迫延期。”

不過我們必須突破Sun的財務難題，繼續將關注重點放在Java周邊系統身上。Sun出爾反爾地公布了Java標準化計劃，并創造出屬于自己的“標準化”委員會，即Java社區進程組織。該組織最初的建立目的在于為實力雄厚的Java參與者們打造一個共商大事的平臺，而且隨著時間的推移其發展也逐漸步入正軌。然而如今Sun已經成為甲骨文毋庸置疑的附屬，后者則直接忽略掉委員會的各種規則、粗暴行使著自己的一票否決權。

Java社區進程的發展為何受阻？問題不在于開放性，而在于利益爭奪。盡管當時我是以旁觀者的身份看熱鬧，但仍然清楚記得Sun在參與EJB3項目時遭遇的窘境。為什么Java發展進度會一落千丈？這是由于Sun與甲骨文雙方需要將購買或者開發出的產品整合到應用程序服務器當中。一旦新的JavaEE規范出臺，他們也必須保證自己能在市場上率先做出反應。

即使是在同一家公司內部，協調好單一產品的發布都絕非易事，更不用說在多家公司之間了。幸運的是，企業合并給事情帶來了轉機。我一直認為Java社區進程并不是Java進度落后的主要原因。

#p#

將Saucer分離出來

如今，Sun只留存在我們的記憶中，而甲骨文則成為真正的老板。然而為什么Java新版本的發布仍然如此遲緩？最簡單的解釋是，Java項目規模過于龐大。大項目往往行動緩慢且充滿風險。為了解決這個問題，讓我們看看如何幫助Java“減肥”。

首先，甲骨文必須克服自身對客戶端技術的過分依賴。當然，Swing與甲骨文還拿不出JavaFX的有力繼承方案，畢竟在現代Web瀏覽器上開發出效果相同而又不引發新麻煩的機制絕非易事。不過甲骨文需要將客戶牢牢束縛在自己的平臺上——至少他們確實是這么做的。

目前我還不清楚JavaFX或者Java的客戶端戰略能給甲骨文帶來哪些真正的優勢。看起來甲骨文似乎設計出一種技術，用于同VB6、Flash或者某些4GL方案競爭。在現代BYOD多平臺環境下，每位與時俱進的高管人士都希望能在iPad上通過寫寫劃劃完成工作。為什么我們要用客戶端來束縛服務器的能力？擺脫了客戶端，甲骨文很可能不必再面對大量安全延誤，并通過告別《Java零日安全漏洞》以及《如何在計算機中禁用Java》等頭條為自己爭取公關主動性。

不過事實上這種占用了大量資金投入的垂直技術平臺應該被直接剔除并宣判其死刑，因為它對于解決主要矛盾根本毫無貢獻。甲骨文甚至有可能將其添加到其它災難性方案中，例如Java ME，并將其命名為Ordroid。如果甲骨文買下黑莓、將其重組為麾下的新部門并打出“未來的平臺方案”以及“iPhone終結者”之類的唬人口號，投資者們也只會將其視為虛張聲勢的愚蠢方案。

簡單來說，Java語言對于Java平臺已經不再像過去那么重要。另一大負面因素在于，微軟的介入削弱了Java的獨有性，這種不利局面即使在2007年之后的實踐協調活動中也未能得到扭轉。對于甲骨文公司來說，將Java語言從Java平臺中剝離出來并為其單獨規劃日程安排會更加輕松——畢竟甲骨文推出的開發工具既不屬于Java相關業務中的主要組成部分，也沒能得到Java開發人士的廣泛支持。微軟需要考慮Visual Studio版本是否能與下一代.Net以及C#版本相協調，但甲骨文則不必為此擔心。

Java平臺支持多種編程語言，從JavaScript到JRuby再到Scala不一而足。此外，以高性能及可擴展方式支持這類不同技術對于云計算非常重要。如果云計算將成為未來的發展方向，那么Java平臺與甲骨文都需要提前做好準備。目前，Java與甲骨文已經對這一趨勢表示默認。在我們看來，對Ruby、Scala甚至Node.js的廣泛支持已經成為Java平臺的最大特色。然而正因為如此，目前Java平臺更多被視為一種立足根基而非創新引擎。

在為Java平臺選擇合適的支持語言類型方面，我更信任Charles Nutter（JRuby/紅帽）與Martin Odersky（Scala/Typesafe）而非Mark Reinhold（Java SE規范/甲骨文）。我對Reinhold先生絕無絲毫不敬之意，而且已經有證據表明眾多協作嘗試正在進展當中，不過等待Java語言或其它甲骨文附屬項目的發展實在耗去了太多時間。

對于甲骨文在Java領域的領導權來說，這是充滿挑戰的一年。Sun當初做出的許多決定開始回過頭給使用者帶來困擾。我給出的答案是放棄Java客戶端、將JVM與語言的發布周期分離開來，同時專注于將Java打造為一個平臺而非萬能性解決方案。

英文原文：http://www.infoworld.com/d/application-development/java-faces-tough-climb-catch-net-224372