【51CTO獨(dú)家特稿】2010年開發(fā)界最值得期待的一件事就是Java 7的正式發(fā)布（如果Sun，或者說，Sun-Oracle能夠遵守他們在2009年Devoxx大會上做出的承諾的話）。無論Java開發(fā)者們是否喜歡，這個從四、五年前就已經(jīng)開始醞釀、并且經(jīng)歷了數(shù)次延期的Java 7是Sun與Java開發(fā)者社區(qū)高度協(xié)作的成果，其重要性是不可忽視的。然而根據(jù)我們的了解，Java編程語言在此次更新中的改變是極其有限的（參考閱讀：Java 7新特性展望。值得一提的是，文中提到的閉包最后還是被加入進(jìn)了Java 7的日程當(dāng)中，不過開發(fā)者們的反映似乎沒有Sun預(yù)期的那么熱烈）。那么，這次重大的變革都發(fā)生在哪些方面呢？
Java，JDK與Java SE
首先我或許應(yīng)該先解釋一下：Java 7這個用語其實(shí)并不嚴(yán)謹(jǐn)，準(zhǔn)確的說法應(yīng)該是JDK 7或Java SE 7（Java產(chǎn)品的命名規(guī)則一直以混亂著稱，不過基本上我們可以認(rèn)為Java SE等同于JDK。這在JDK的官方下載頁上是可以證實(shí)的）。那么，這個JDK包括了哪些部分？請允許我借用一下JRuby核心開發(fā)者之一，Ola Bini在一次演示上用過的簡圖：
圖中的JVM即Java虛擬機(jī)（在Java SE中特指Sun的HopSpot），API即Java語言API類庫，Java Language即Java編程語言。確切的說，鑒于用JDK開發(fā)Java程序的開發(fā)者們是自己寫的代碼而此代碼并非是隨JDK附送的，此處的Java編程語言理解為javac（編譯器）更加合適。
當(dāng)然，JDK比上面這張圖要復(fù)雜的多。感興趣的讀者們可以研究下面這張圖進(jìn)行進(jìn)一步了解：
Java的強(qiáng)大與成功
我們都知道，Java代碼的處理方式是先由javac把代碼編譯成JVM看得懂的字節(jié)碼，然后JVM就好像解釋器一樣把這些字節(jié)碼執(zhí)行出來。因此，無論是怎樣的平臺，只要上面有合適的JVM就能跑Java程序，這促成了其“編寫一次，到處運(yùn)行”的特性。這成為Java強(qiáng)大——因而成功——的重要原因之一。（當(dāng)然，這是一個理想化的境界。出于技術(shù)因素以及不同平臺上的JVM成分復(fù)雜的關(guān)系，“編寫一次”之后要“到處運(yùn)行”往往仍會需要一些代碼的改動。）
除了跨平臺特性之外，Java的成功還有很多其他因素，下面選取了幾個比較有代表性的觀點(diǎn)供讀者們參考：
◆完全的面向?qū)ο蟆踔吝B字節(jié)碼都保持著對象結(jié)構(gòu)
◆完善的類庫
◆自身攜帶的線程類庫可以進(jìn)行多進(jìn)程處理
◆自身攜帶很多網(wǎng)絡(luò)功能類庫
◆JVM中的垃圾回收器（GC）可以進(jìn)行自動內(nèi)存管理
◆編譯+解釋的雙重步驟和GC機(jī)制等因素提升了安全性
◆JVM的性能還不算糟糕，隨著JIT編譯等技術(shù)的出現(xiàn)還越來越好
其他語言的進(jìn)駐
JVM上最初只運(yùn)行Java代碼。不過由于其運(yùn)行機(jī)制，如果通過“特制”的編譯器將用其他編程語言書寫的代碼編譯為Java字節(jié)碼，那么非Java代碼也可以運(yùn)行在JVM之上。編者目前還沒有考察出第一位登陸JVM的非Java語言是誰以及確切的登陸時間，然而對于1995年誕生的Java，JRuby的另一位核心開發(fā)者Charles Nutter曾經(jīng)在08年評論說：“幾乎每一個超過五歲的編程語言都或多或少有自己的JVM運(yùn)行版?！毕旅媸沁@個列表的一部分：
那句廣告詞是怎么說的？哪個餐館吃飯的人多，那個餐館的飯菜一定差不了。那么，JVM這個餐館究竟好在哪里？
其實(shí)在上面介紹的Java成功的因素中，有三條都是與JVM相關(guān)的，即它的垃圾回收機(jī)制、安全性以及性能。事實(shí)上這也差不多概括了所有JVM的好處了。在性能這一點(diǎn)上或許有待商榷，不過自從JIT編譯技術(shù)應(yīng)用在JVM上之后，據(jù)說其性能已經(jīng)接近了C++的級別；而在JDK 7當(dāng)中也承諾會有性能的大幅提升。另外，JDK 7即將使用的全新垃圾回收器G1也承諾將帶來更好的并發(fā)性、可預(yù)測性以及性能。
據(jù)Java之父James Gosling使用過的一個統(tǒng)計，世界上有超過8億5千萬臺桌面設(shè)備啟用了Java（即，至少安裝了JRE），還有100億臺具有Java功能的設(shè)備。JVM這樣一個質(zhì)量好名氣又大的舞臺，誰會不想上去跳幾步？
Java語言的衰老
在這些進(jìn)駐JVM平臺的語言中，有好幾個都是專門定位于JVM的新語言（而非其他現(xiàn)成語言的JVM版本），其中以Clojure、Groovy和Scala為代表。而這些語言的創(chuàng)始人們都不約而同的表示過自己對Java語言的厭倦與失望。Clojure的創(chuàng)始人Rick Hickey說：“我想要一個動態(tài)的、富有表達(dá)力的、函數(shù)式的語言?！盙roovy的創(chuàng)始人James Strachan說：“Java是一種令人驚嘆的復(fù)雜語言，它的語法規(guī)范長達(dá)600頁，我懷疑到底有沒有人能真正理解它?！盝ames在去年的一篇廣為流傳的博文中表達(dá)了自己對Scala語言的看好，而Scala語言的創(chuàng)始人Martin Odersky則是這樣描述Java的：
“經(jīng)過Pizza和GJ的經(jīng)歷，我有時會感到沮喪，因為Java是一個具有非常強(qiáng)的約束的語言。因此，很多事情都不能像我想象的那種方式那樣去做——那種我原本確信是正確的方式?！渲凶顝?qiáng)、最難以應(yīng)付的是，它必須充分地向后兼容非泛型Java?！?/p>
在09年7月的51CTO編程語言排行榜上，red7對Java語言的弱勢進(jìn)行了一番總結(jié)，觀點(diǎn)如下：“……Java的進(jìn)化速度在最近幾年已經(jīng)遠(yuǎn)遠(yuǎn)無法追趕日趨復(fù)雜項目需求和苛刻的交付日期。人們開始嘗試各種開源項目以緩解Java在某些方面的不足，以Hibernate和Spring為代表的框架快速發(fā)展和普及；另一方面，Sun和JCP的各種標(biāo)準(zhǔn)不斷遭到人們的質(zhì)疑，JSF和JPA等官方框架被大多數(shù)開發(fā)者拋在一邊。而這背后，是Sun和JCP對新需求的麻木和對社區(qū)的漠視，這直接導(dǎo)致Java的更新落后于變化，Java正在新變化新需求中變得緩慢和老態(tài)?！敝劣诟泳唧w的方面，Java程序員、架構(gòu)師，LambdaJ的作者M(jìn)ario Fusco的這篇博文對Java語言特性的老化進(jìn)行了全面的總結(jié)。
衰老中的Java語言王者之風(fēng)猶存，但既然JVM是一個如此優(yōu)秀而開放的平臺，由更加年輕、功能更加強(qiáng)大的語言來承接JVM這個舞臺，相信也是Java愿意看到的。事實(shí)上，Java之父自己也清楚的表述了這個觀點(diǎn)：“我們看中的并非Java語言，而是JVM。事實(shí)上我們可以讓所有語言一起工作。”同時，Sun自己也在2008年初啟動了一個叫做Da Vinci Machine（達(dá)芬奇機(jī)器）的項目，試圖讓JVM更好的支持所有動態(tài)語言。而這個項目的一個重要組成部分，JSR 292（Java平臺的動態(tài)語言支持），也將在JDK 7當(dāng)中實(shí)現(xiàn)。如果成功的話，動態(tài)語言在JVM上的性能會得到飛一般的提升，甚至可以和Java語言本身相媲美。
我們需要怎樣的語言？
無論Java語言的支持者們是如何反對這種在他們看來有些舍本逐末的行為，事實(shí)正在逐漸證明這個推送JVM的方向是進(jìn)步的，而且是受開發(fā)者們歡迎的（比如Groovy的開發(fā)者們大多都表示慶幸自己從Java投向了Groovy，并且翹首期待JSR 292的到來）。這是一個開放的時代，語言的好處和語言的糟糕之處都可以輕易地飄到那些項目經(jīng)理的耳朵里，而接下來，項目經(jīng)理的下定決心只是一個時間問題。
那么，項目經(jīng)理們需要什么？或者說，以后的企業(yè)級項目和Web項目需要怎樣的語言？一般而言，有下面幾點(diǎn)：
◆可伸縮性
◆可移植性
◆并行編程
◆高性能的
◆DSL（領(lǐng)域特定語言）的實(shí)現(xiàn)
當(dāng)然還有對于低風(fēng)險的要求，比如與舊項目的兼容性，舊項目遷移的成本，開發(fā)工具的支持，開發(fā)團(tuán)隊對語言的熟悉情況，以及語言開發(fā)團(tuán)隊的穩(wěn)定性等等。而具體到每一位開發(fā)者頭上，那么情況變得更加復(fù)雜。他們可能想要：
◆動態(tài)的
◆靜態(tài)的
◆強(qiáng)類型的
◆函數(shù)式的
◆富有表達(dá)力的
◆面向?qū)ο蟮?br>◆簡潔的
◆容易理解的
◆容易學(xué)習(xí)的（在有Java或其他語言開發(fā)經(jīng)驗的基礎(chǔ)上）
◆深刻的
◆快捷的
◆模塊化的
◆靈活的
◆有強(qiáng)大的類庫
◆有好用的框架
◆有合適的IDE
◆有活躍的社區(qū)
……
某些語言能夠滿足上述條件中的很多條，但是很明顯，沒有任何一種語言能夠滿足所有的條件！同時，同一個項目的不同層面的需求也是不同的?，F(xiàn)在全世界最流行的微博服務(wù)Twitter，表層是Ruby on Rails，底層是Scala，而Twitter團(tuán)隊進(jìn)行這樣的選擇正是因為考慮到不同層面的業(yè)務(wù)需求。
事實(shí)上，這種多語言編程(Multi-lingual programming)，或者叫做混合語言編程(Polyglot Programming)并不是一個新概念，這個理念的成功案例可以追述到二十多年前，當(dāng)時誕生的而至今在開發(fā)者社區(qū)中仍然火熱無比的Emacs正是一個C語言與Lisp方言的混合產(chǎn)物。對于多語言編程適用的層次，請允許我再次借用Ola Bini的一個預(yù)言，在預(yù)言中他描述了同一個項目中可能會需要不同語言的三個層：
◆穩(wěn)定層（stable layer）–不包含大量的應(yīng)用程序功能，可以使用靜態(tài)語言構(gòu)建
◆動態(tài)層（dynamic layer）- 包含大量的應(yīng)用程序功能，使用動態(tài)語言構(gòu)建
◆領(lǐng)域?qū)樱╠omain layer）- 包含大量的應(yīng)用程序功能，使用DSL構(gòu)建
Twitter這樣的成功案例剛好支持了這樣的預(yù)測，因為Scala是一個強(qiáng)大的靜態(tài)語言，而Ruby不僅是一個動態(tài)語言，還是一個十分適合編寫DSL的語言。
百家爭鳴的JVM
不過話又說回來了，既然混合語言編程這么好，為什么一直以來都沒怎么流行呢？答案很簡單，和我們與國際友人之間有溝通問題的原因是一樣的：一段Ruby代碼要如何明白一段Java代碼說了些什么呢？對于高級語言來說，要互相理解對方的功能，進(jìn)而進(jìn)行交互，是一件很困難的事情。如果無法交互，又要如何一起來完成同一個項目呢？
溝通問題是一個很大的障礙。然而，這個障礙的清除早就有了一個成功的案例：那就是微軟的.NET平臺。在微軟官方文檔的描述中，這種“溝通”被命名為“跨語言互操作性”，或者“語言互用性”。在.NET平臺上，這個問題的解決方案是公共語言規(guī)范 (CLS)。事實(shí)上，不得不說微軟在這方面做的要遠(yuǎn)遠(yuǎn)超過解決“溝通問題”的這個層面：它的目的是能夠讓多種語言可以自由共享和擴(kuò)展彼此的庫。不過，在過去的很長一段時間內(nèi)，.NET平臺上的主要公民只有兩個：C#和VB.NET，其他公民則大多半死不活，這使得這個互操作性的意義大打折扣。
然而JVM現(xiàn)在的情況似乎非常樂觀：且不說Groovy、Scala這種專門針對JVM而創(chuàng)建的語言活的挺滋潤（這兩個語言都可以直接使用Java類庫，據(jù)說是所有的），就是移植到JVM上的語言，尤其是JRuby和Jython，看起來活的都不錯，足以讓它們在面對IronRuby和IronPython的時候高興的挺起腰板。
結(jié)語
綜上所述，軟件項目的未來在于混合語言編程。此前景的舞臺將在未來數(shù)年內(nèi)搭建成熟，而聚光燈的焦點(diǎn)就是一個百家爭鳴的JVM。觀望此番前景，我們在近日的51CTO Java頻道改版中特意新添了一欄目，名為Java+，目的正是觀察基于JVM的混合語言編程的發(fā)展趨勢，為Java開發(fā)者們提供指引。想一想看，當(dāng)你的老板或項目經(jīng)理決定要嘗試Groovy或是Scala進(jìn)行部分開發(fā)的時候，如果你能夠立即站出來為他進(jìn)行一些解惑或指點(diǎn)，那么你又何愁飯碗隨著Java語言的老去而消逝呢？
現(xiàn)在就開始學(xué)習(xí)吧。
你未來可能會用到JVM上的哪些其他語言？你是否已經(jīng)在學(xué)習(xí)、使用這些語言，或者計劃學(xué)習(xí)這些語言？談?wù)勀愕目捶ò?/a>。
