【51CTO獨家特稿】2010年開發界最值得期待的一件事就是Java 7的正式發布（如果Sun，或者說，Sun-Oracle能夠遵守他們在2009年Devoxx大會上做出的承諾的話）。無論Java開發者們是否喜歡，這個從四、五年前就已經開始醞釀、并且經歷了數次延期的Java 7是Sun與Java開發者社區高度協作的成果，其重要性是不可忽視的。然而根據我們的了解，Java編程語言在此次更新中的改變是極其有限的（參考閱讀：Java 7新特性展望。值得一提的是，文中提到的閉包最后還是被加入進了Java 7的日程當中，不過開發者們的反映似乎沒有Sun預期的那么熱烈）。那么，這次重大的變革都發生在哪些方面呢？

Java，JDK與Java SE

首先我或許應該先解釋一下：Java 7這個用語其實并不嚴謹，準確的說法應該是JDK 7或Java SE 7（Java產品的命名規則一直以混亂著稱，不過基本上我們可以認為Java SE等同于JDK。這在JDK的官方下載頁上是可以證實的）。那么，這個JDK包括了哪些部分？請允許我借用一下JRuby核心開發者之一，Ola Bini在一次演示上用過的簡圖：

圖中的JVM即Java虛擬機（在Java SE中特指Sun的HopSpot），API即Java語言API類庫，Java Language即Java編程語言。確切的說，鑒于用JDK開發Java程序的開發者們是自己寫的代碼而此代碼并非是隨JDK附送的，此處的Java編程語言理解為javac（編譯器）更加合適。

當然，JDK比上面這張圖要復雜的多。感興趣的讀者們可以研究下面這張圖進行進一步了解：

Java的強大與成功

我們都知道，Java代碼的處理方式是先由javac把代碼編譯成JVM看得懂的字節碼，然后JVM就好像解釋器一樣把這些字節碼執行出來。因此，無論是怎樣的平臺，只要上面有合適的JVM就能跑Java程序，這促成了其“編寫一次，到處運行”的特性。這成為Java強大——因而成功——的重要原因之一。（當然，這是一個理想化的境界。出于技術因素以及不同平臺上的JVM成分復雜的關系，“編寫一次”之后要“到處運行”往往仍會需要一些代碼的改動。）

除了跨平臺特性之外，Java的成功還有很多其他因素，下面選取了幾個比較有代表性的觀點供讀者們參考：

◆完全的面向對象——甚至連字節碼都保持著對象結構

◆完善的類庫

◆自身攜帶的線程類庫可以進行多進程處理

◆自身攜帶很多網絡功能類庫

◆JVM中的垃圾回收器（GC）可以進行自動內存管理

◆編譯+解釋的雙重步驟和GC機制等因素提升了安全性

◆JVM的性能還不算糟糕，隨著JIT編譯等技術的出現還越來越好

其他語言的進駐

JVM上最初只運行Java代碼。不過由于其運行機制，如果通過“特制”的編譯器將用其他編程語言書寫的代碼編譯為Java字節碼，那么非Java代碼也可以運行在JVM之上。編者目前還沒有考察出第一位登陸JVM的非Java語言是誰以及確切的登陸時間，然而對于1995年誕生的Java，JRuby的另一位核心開發者Charles Nutter曾經在08年評論說：“幾乎每一個超過五歲的編程語言都或多或少有自己的JVM運行版。”下面是這個列表的一部分：

那句廣告詞是怎么說的？哪個餐館吃飯的人多，那個餐館的飯菜一定差不了。那么，JVM這個餐館究竟好在哪里？

其實在上面介紹的Java成功的因素中，有三條都是與JVM相關的，即它的垃圾回收機制、安全性以及性能。事實上這也差不多概括了所有JVM的好處了。在性能這一點上或許有待商榷，不過自從JIT編譯技術應用在JVM上之后，據說其性能已經接近了C++的級別；而在JDK 7當中也承諾會有性能的大幅提升。另外，JDK 7即將使用的全新垃圾回收器G1也承諾將帶來更好的并發性、可預測性以及性能。

據Java之父James Gosling使用過的一個統計，世界上有超過8億5千萬臺桌面設備啟用了Java（即，至少安裝了JRE），還有100億臺具有Java功能的設備。JVM這樣一個質量好名氣又大的舞臺，誰會不想上去跳幾步？

Java語言的衰老

在這些進駐JVM平臺的語言中，有好幾個都是專門定位于JVM的新語言（而非其他現成語言的JVM版本），其中以Clojure、Groovy和Scala為代表。而這些語言的創始人們都不約而同的表示過自己對Java語言的厭倦與失望。Clojure的創始人Rick Hickey說：“我想要一個動態的、富有表達力的、函數式的語言。”Groovy的創始人James Strachan說：“Java是一種令人驚嘆的復雜語言，它的語法規范長達600頁，我懷疑到底有沒有人能真正理解它。”James在去年的一篇廣為流傳的博文中表達了自己對Scala語言的看好，而Scala語言的創始人Martin Odersky則是這樣描述Java的：

“經過Pizza和GJ的經歷，我有時會感到沮喪，因為Java是一個具有非常強的約束的語言。因此，很多事情都不能像我想象的那種方式那樣去做——那種我原本確信是正確的方式。……其中最強、最難以應付的是，它必須充分地向后兼容非泛型Java。”

在09年7月的51CTO編程語言排行榜上，red7對Java語言的弱勢進行了一番總結，觀點如下：“……Java的進化速度在最近幾年已經遠遠無法追趕日趨復雜項目需求和苛刻的交付日期。人們開始嘗試各種開源項目以緩解Java在某些方面的不足，以Hibernate和Spring為代表的框架快速發展和普及；另一方面，Sun和JCP的各種標準不斷遭到人們的質疑，JSF和JPA等官方框架被大多數開發者拋在一邊。而這背后，是Sun和JCP對新需求的麻木和對社區的漠視，這直接導致Java的更新落后于變化，Java正在新變化新需求中變得緩慢和老態。”至于更加具體的方面，Java程序員、架構師，LambdaJ的作者Mario Fusco的這篇博文對Java語言特性的老化進行了全面的總結。

衰老中的Java語言王者之風猶存，但既然JVM是一個如此優秀而開放的平臺，由更加年輕、功能更加強大的語言來承接JVM這個舞臺，相信也是Java愿意看到的。事實上，Java之父自己也清楚的表述了這個觀點：“我們看中的并非Java語言，而是JVM。事實上我們可以讓所有語言一起工作。”同時，Sun自己也在2008年初啟動了一個叫做Da Vinci Machine（達芬奇機器）的項目，試圖讓JVM更好的支持所有動態語言。而這個項目的一個重要組成部分，JSR 292（Java平臺的動態語言支持），也將在JDK 7當中實現。如果成功的話，動態語言在JVM上的性能會得到飛一般的提升，甚至可以和Java語言本身相媲美。

我們需要怎樣的語言？

無論Java語言的支持者們是如何反對這種在他們看來有些舍本逐末的行為，事實正在逐漸證明這個推送JVM的方向是進步的，而且是受開發者們歡迎的（比如Groovy的開發者們大多都表示慶幸自己從Java投向了Groovy，并且翹首期待JSR 292的到來）。這是一個開放的時代，語言的好處和語言的糟糕之處都可以輕易地飄到那些項目經理的耳朵里，而接下來，項目經理的下定決心只是一個時間問題。

那么，項目經理們需要什么？或者說，以后的企業級項目和Web項目需要怎樣的語言？一般而言，有下面幾點：
◆可伸縮性
◆可移植性
◆并行編程
◆高性能的
◆DSL（領域特定語言）的實現

當然還有對于低風險的要求，比如與舊項目的兼容性，舊項目遷移的成本，開發工具的支持，開發團隊對語言的熟悉情況，以及語言開發團隊的穩定性等等。而具體到每一位開發者頭上，那么情況變得更加復雜。他們可能想要：
◆動態的
◆靜態的
◆強類型的
◆函數式的
◆富有表達力的
◆面向對象的
◆簡潔的
◆容易理解的
◆容易學習的（在有Java或其他語言開發經驗的基礎上）
◆深刻的
◆快捷的
◆模塊化的
◆靈活的
◆有強大的類庫
◆有好用的框架
◆有合適的IDE
◆有活躍的社區
……

某些語言能夠滿足上述條件中的很多條，但是很明顯，沒有任何一種語言能夠滿足所有的條件！同時，同一個項目的不同層面的需求也是不同的。現在全世界最流行的微博服務Twitter，表層是Ruby on Rails，底層是Scala，而Twitter團隊進行這樣的選擇正是因為考慮到不同層面的業務需求。

事實上，這種多語言編程(Multi-lingual programming)，或者叫做混合語言編程(Polyglot Programming)并不是一個新概念，這個理念的成功案例可以追述到二十多年前，當時誕生的而至今在開發者社區中仍然火熱無比的Emacs正是一個C語言與Lisp方言的混合產物。對于多語言編程適用的層次，請允許我再次借用Ola Bini的一個預言，在預言中他描述了同一個項目中可能會需要不同語言的三個層：
◆穩定層（stable layer）–不包含大量的應用程序功能，可以使用靜態語言構建
◆動態層（dynamic layer）- 包含大量的應用程序功能，使用動態語言構建
◆領域層（domain layer）- 包含大量的應用程序功能，使用DSL構建

Twitter這樣的成功案例剛好支持了這樣的預測，因為Scala是一個強大的靜態語言，而Ruby不僅是一個動態語言，還是一個十分適合編寫DSL的語言。

百家爭鳴的JVM

不過話又說回來了，既然混合語言編程這么好，為什么一直以來都沒怎么流行呢？答案很簡單，和我們與國際友人之間有溝通問題的原因是一樣的：一段Ruby代碼要如何明白一段Java代碼說了些什么呢？對于高級語言來說，要互相理解對方的功能，進而進行交互，是一件很困難的事情。如果無法交互，又要如何一起來完成同一個項目呢？

溝通問題是一個很大的障礙。然而，這個障礙的清除早就有了一個成功的案例：那就是微軟的.NET平臺。在微軟官方文檔的描述中，這種“溝通”被命名為“跨語言互操作性”，或者“語言互用性”。在.NET平臺上，這個問題的解決方案是公共語言規范 (CLS)。事實上，不得不說微軟在這方面做的要遠遠超過解決“溝通問題”的這個層面：它的目的是能夠讓多種語言可以自由共享和擴展彼此的庫。不過，在過去的很長一段時間內，.NET平臺上的主要公民只有兩個：C#和VB.NET，其他公民則大多半死不活，這使得這個互操作性的意義大打折扣。

然而JVM現在的情況似乎非常樂觀：且不說Groovy、Scala這種專門針對JVM而創建的語言活的挺滋潤（這兩個語言都可以直接使用Java類庫，據說是所有的），就是移植到JVM上的語言，尤其是JRuby和Jython，看起來活的都不錯，足以讓它們在面對IronRuby和IronPython的時候高興的挺起腰板。

#t#為什么.NET在多語言之路走了很久的路仍然青黃不接，而JVM已經儼然呈現出一幅百家爭鳴之態？答案很明顯：因為Java是開源的！（準確的說，那些語言開發者們需要掌握的部分都是開源的，而開源社區的創造力顯然要遠遠超過微軟那雖然不算少但仍然精力有限的開發團隊。）語言互操作只是第一步，隨著開放理念的前行，平臺的互操作，標準的互操作都將逐步跟進，屆時Java的開源性質將使JVM上的百花綻放的更加鮮艷，而混合語言項目則會發現Java平臺是他們最理想的去處。

結語

綜上所述，軟件項目的未來在于混合語言編程。此前景的舞臺將在未來數年內搭建成熟，而聚光燈的焦點就是一個百家爭鳴的JVM。觀望此番前景，我們在近日的51CTO Java頻道改版中特意新添了一欄目，名為Java+，目的正是觀察基于JVM的混合語言編程的發展趨勢，為Java開發者們提供指引。想一想看，當你的老板或項目經理決定要嘗試Groovy或是Scala進行部分開發的時候，如果你能夠立即站出來為他進行一些解惑或指點，那么你又何愁飯碗隨著Java語言的老去而消逝呢？

現在就開始學習吧。

你未來可能會用到JVM上的哪些其他語言？你是否已經在學習、使用這些語言，或者計劃學習這些語言？談談你的看法吧。