---待到Java 8面世之時(shí) .Net的進(jìn)度時(shí)鐘恐怕已經(jīng)又走過(guò)了兩到五年——屆時(shí)微軟做出的調(diào)整將使二者差距進(jìn)一步拉大。

就在幾周之前，我詳細(xì)介紹了Java 8中值得期待的幾大主要功能。不過(guò)當(dāng)時(shí)我并沒(méi)有提到.Net的新變化，事實(shí)上Java 8中的大部分（甚至全部）功能都能在.Net中找到。更夸張的是，不少將被推遲到Java 9中實(shí)現(xiàn)的功能也將在.Net中出現(xiàn)。我并不贊成將一切功能盲目塞進(jìn)Java語(yǔ)言的激進(jìn)行為，不過(guò)我認(rèn)為Java平臺(tái)（相對(duì)于語(yǔ)言本身）確實(shí)應(yīng)該在功能多樣性方面下點(diǎn)功夫。在我看來(lái)，.Net技術(shù)堪稱杰出，C#與.Net平臺(tái)自Java 3時(shí)代就開(kāi)始在各個(gè)方面迎頭趕上。就個(gè)人而言，我對(duì)微軟的操作系統(tǒng)非常抵觸，而且很擔(dān)心無(wú)法修復(fù)討厭的bug（至少在理論上不行）。

兩套平臺(tái)、一個(gè)故事

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

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

Java 1.4給我們帶來(lái)了NIO（即網(wǎng)絡(luò)接口對(duì)象）與正則表達(dá)式，與前代版本相隔不到兩年。Java 1.4.2則在多核環(huán)境中實(shí)現(xiàn)了垃圾收集功能（雖然還不太穩(wěn)定），開(kāi)發(fā)周期為一年。接下來(lái)是Java 1.5，這個(gè)開(kāi)發(fā)周期超過(guò)一年的新版本將并發(fā)一致性GC引入生產(chǎn)流程，并且加入了其它一些重要的并發(fā)及NIO功能。

Java 1.6將關(guān)注重點(diǎn)放在性能節(jié)約方面，雖然效果還算顯著，但其改進(jìn)幅度仍然無(wú)法與1.5版本相提并論、更遑論用去了無(wú)數(shù)開(kāi)發(fā)者兩年的等待時(shí)間。Java 1.7是自1.4.2以來(lái)第一個(gè)針對(duì)底層虛擬機(jī)技術(shù)（G1 collector）做出大幅改動(dòng)的新版本，利用invokedynamic指令幫助我們?cè)贘VM環(huán)境下更好地與其它語(yǔ)言對(duì)接。盡管屬于大版本升級(jí)，但五年的更新周期無(wú)疑標(biāo)志著Java的迭代步伐已經(jīng)明顯放緩。

Sample features in Java and .Net and their release dates

進(jìn)展為何如何緩慢？

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

互聯(lián)網(wǎng)經(jīng)濟(jì)的泡沫最終煙消云散，Sun公司決定將手中已經(jīng)建成的大型設(shè)備集群轉(zhuǎn)化為“商業(yè)化”計(jì)算硬件業(yè)務(wù)?？偠灾?，Sun在硬件業(yè)務(wù)方面押下了錯(cuò)誤的賭注。

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

甲骨文在一份典型的簡(jiǎn)要公開(kāi)聲明中，承認(rèn)某些業(yè)務(wù)及政治問(wèn)題拖延了Java 7的發(fā)布進(jìn)度。“眾所周知，由于各種業(yè)務(wù)及政治問(wèn)題的影響，最新版本的推出被迫延期。”

不過(guò)我們必須突破Sun的財(cái)務(wù)難題，繼續(xù)將關(guān)注重點(diǎn)放在Java周邊系統(tǒng)身上。Sun出爾反爾地公布了Java標(biāo)準(zhǔn)化計(jì)劃，并創(chuàng)造出屬于自己的“標(biāo)準(zhǔn)化”委員會(huì)，即Java社區(qū)進(jìn)程組織。該組織最初的建立目的在于為實(shí)力雄厚的Java參與者們打造一個(gè)共商大事的平臺(tái)，而且隨著時(shí)間的推移其發(fā)展也逐漸步入正軌。然而如今Sun已經(jīng)成為甲骨文毋庸置疑的附屬，后者則直接忽略掉委員會(huì)的各種規(guī)則、粗暴行使著自己的一票否決權(quán)。

Java社區(qū)進(jìn)程的發(fā)展為何受阻？問(wèn)題不在于開(kāi)放性，而在于利益爭(zhēng)奪。盡管當(dāng)時(shí)我是以旁觀者的身份看熱鬧，但仍然清楚記得Sun在參與EJB3項(xiàng)目時(shí)遭遇的窘境。為什么Java發(fā)展進(jìn)度會(huì)一落千丈？這是由于Sun與甲骨文雙方需要將購(gòu)買或者開(kāi)發(fā)出的產(chǎn)品整合到應(yīng)用程序服務(wù)器當(dāng)中。一旦新的JavaEE規(guī)范出臺(tái)，他們也必須保證自己能在市場(chǎng)上率先做出反應(yīng)。

即使是在同一家公司內(nèi)部，協(xié)調(diào)好單一產(chǎn)品的發(fā)布都絕非易事，更不用說(shuō)在多家公司之間了。幸運(yùn)的是，企業(yè)合并給事情帶來(lái)了轉(zhuǎn)機(jī)。我一直認(rèn)為Java社區(qū)進(jìn)程并不是Java進(jìn)度落后的主要原因。

#p#

將Saucer分離出來(lái)

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

首先，甲骨文必須克服自身對(duì)客戶端技術(shù)的過(guò)分依賴。當(dāng)然，Swing與甲骨文還拿不出JavaFX的有力繼承方案，畢竟在現(xiàn)代Web瀏覽器上開(kāi)發(fā)出效果相同而又不引發(fā)新麻煩的機(jī)制絕非易事。不過(guò)甲骨文需要將客戶牢牢束縛在自己的平臺(tái)上——至少他們確實(shí)是這么做的。

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

不過(guò)事實(shí)上這種占用了大量資金投入的垂直技術(shù)平臺(tái)應(yīng)該被直接剔除并宣判其死刑，因?yàn)樗鼘?duì)于解決主要矛盾根本毫無(wú)貢獻(xiàn)。甲骨文甚至有可能將其添加到其它災(zāi)難性方案中，例如Java ME，并將其命名為Ordroid。如果甲骨文買下黑莓、將其重組為麾下的新部門并打出“未來(lái)的平臺(tái)方案”以及“iPhone終結(jié)者”之類的唬人口號(hào)，投資者們也只會(huì)將其視為虛張聲勢(shì)的愚蠢方案。

簡(jiǎn)單來(lái)說(shuō)，Java語(yǔ)言對(duì)于Java平臺(tái)已經(jīng)不再像過(guò)去那么重要。另一大負(fù)面因素在于，微軟的介入削弱了Java的獨(dú)有性，這種不利局面即使在2007年之后的實(shí)踐協(xié)調(diào)活動(dòng)中也未能得到扭轉(zhuǎn)。對(duì)于甲骨文公司來(lái)說(shuō)，將Java語(yǔ)言從Java平臺(tái)中剝離出來(lái)并為其單獨(dú)規(guī)劃日程安排會(huì)更加輕松——畢竟甲骨文推出的開(kāi)發(fā)工具既不屬于Java相關(guān)業(yè)務(wù)中的主要組成部分，也沒(méi)能得到Java開(kāi)發(fā)人士的廣泛支持。微軟需要考慮Visual Studio版本是否能與下一代.Net以及C#版本相協(xié)調(diào)，但甲骨文則不必為此擔(dān)心。

Java平臺(tái)支持多種編程語(yǔ)言，從JavaScript到JRuby再到Scala不一而足。此外，以高性能及可擴(kuò)展方式支持這類不同技術(shù)對(duì)于云計(jì)算非常重要。如果云計(jì)算將成為未來(lái)的發(fā)展方向，那么Java平臺(tái)與甲骨文都需要提前做好準(zhǔn)備。目前，Java與甲骨文已經(jīng)對(duì)這一趨勢(shì)表示默認(rèn)。在我們看來(lái)，對(duì)Ruby、Scala甚至Node.js的廣泛支持已經(jīng)成為Java平臺(tái)的最大特色。然而正因?yàn)槿绱耍壳癑ava平臺(tái)更多被視為一種立足根基而非創(chuàng)新引擎。

在為Java平臺(tái)選擇合適的支持語(yǔ)言類型方面，我更信任Charles Nutter（JRuby/紅帽）與Martin Odersky（Scala/Typesafe）而非Mark Reinhold（Java SE規(guī)范/甲骨文）。我對(duì)Reinhold先生絕無(wú)絲毫不敬之意，而且已經(jīng)有證據(jù)表明眾多協(xié)作嘗試正在進(jìn)展當(dāng)中，不過(guò)等待Java語(yǔ)言或其它甲骨文附屬項(xiàng)目的發(fā)展實(shí)在耗去了太多時(shí)間。

對(duì)于甲骨文在Java領(lǐng)域的領(lǐng)導(dǎo)權(quán)來(lái)說(shuō)，這是充滿挑戰(zhàn)的一年。Sun當(dāng)初做出的許多決定開(kāi)始回過(guò)頭給使用者帶來(lái)困擾。我給出的答案是放棄Java客戶端、將JVM與語(yǔ)言的發(fā)布周期分離開(kāi)來(lái)，同時(shí)專注于將Java打造為一個(gè)平臺(tái)而非萬(wàn)能性解決方案。

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