【51CTO 9月27日外電頭條】我們?cè)恢灰淮蔚奶岬?a target="_blank" >基于JVM的語(yǔ)言正在開(kāi)始流行，Java程序員和Java平臺(tái)本身正在走向混合編程時(shí)代。目前，基于JVM的語(yǔ)言有Scala、Groovy、Clojure等，但這些語(yǔ)言哪一個(gè)會(huì)成為未來(lái)JVM上的主力？

近日在舊金山舉行的JavaOne 2010大會(huì)上，OpenGamma的技術(shù)工程師兼Joda Time開(kāi)源API項(xiàng)目組長(zhǎng)斯蒂芬·科爾伯恩與Artima主席比爾·文納斯就“下一代大型 JVM語(yǔ)言”展開(kāi)了一場(chǎng)對(duì)話。在這一對(duì)話中，史提芬表達(dá)了對(duì)于下一代大型語(yǔ)言的思考。

你認(rèn)為哪種語(yǔ)言將成為下一代大型JVM語(yǔ)言？

首先，我認(rèn)為，想一想 Java 給予我們的教訓(xùn)對(duì)這個(gè)問(wèn)題是有幫助的。Java哪里做錯(cuò)了？哪里做對(duì)了？以后我們要怎么做？在這種語(yǔ)境下，其他主要的替代語(yǔ)言（Groovy, Scala, Clojure、Fantom）是否有可能成為下一代大型JVM語(yǔ)言？

那么，我們從 Java 得到的教訓(xùn)是什么？如果我們可以重新來(lái)過(guò)，我們會(huì)回避許多東西，如暴露的基本數(shù)據(jù)類型（exposed primitives）、暴露的整列以及檢查型異常（checked exception），我們不會(huì)把這些東西放到語(yǔ)言中。

然后，是一些我們想要在新語(yǔ)言中實(shí)現(xiàn)的東西。很明顯，一種更優(yōu)秀的模塊化方案是其中之一。但是，Java 中的模塊化，我們一直在說(shuō)這事，并不是真正我們想要的。事實(shí)上，我們可以不再編譯至類文件，而是只編譯至模塊。編譯器不再輸出類文件，而只輸出模塊。我們有時(shí)可以在模塊系統(tǒng)中添加一項(xiàng)行得通的功能，確定版本 1.1 是否與版本 1.2 兼容。模塊系統(tǒng)檢查所有我們所用的方法的字節(jié)碼，并作出判斷， 因?yàn)槟闼玫娜糠椒ǖ淖止?jié)碼沒(méi)有變化，因此 1.1 和 1.2 對(duì)于你來(lái)說(shuō)是完全兼容的。雖然還有好多事需要做，但是有些這些事情需要一點(diǎn)反思。

現(xiàn)在，我們有4 門(mén)主要的語(yǔ)言可供選擇：Groovy, Scala, Clojure、Fantom，這些語(yǔ)言怎么樣呢？

Clojure所用Lisp語(yǔ)法。這對(duì)Java開(kāi)發(fā)者帶來(lái)了很大的困難，所以，看起來(lái)它不可能成為下一代大型語(yǔ)言，即使它有一些很棒的創(chuàng)意。

Groovy是一個(gè)不同的小語(yǔ)種，它在功能方面填補(bǔ)了Java對(duì)于腳本語(yǔ)言的需求。構(gòu)建腳本方面，Groovy將會(huì)扮演一個(gè)角色，尤其是結(jié)合 Gradle。也許在web應(yīng)用程序方面也會(huì)有重要的作用。

其他兩門(mén)語(yǔ)言：Scala 和Fantom，有些類似，他們都是靜態(tài)類型的，但他們處理類型系統(tǒng)的方式完全相反。從某種程度上，Scala 已經(jīng)一路奔向類型系統(tǒng)了；如果我理解的沒(méi)錯(cuò)，你可以在Scala 泛型內(nèi)作出一種圖靈完備性（Turing-complete）的語(yǔ)言。更多關(guān)于Scala語(yǔ)言的介紹可以參考51CTO專題：Scala編程語(yǔ)言。

Fantom 走向了另一個(gè)方向，弱化了類型系統(tǒng)。對(duì)于這兩種語(yǔ)言，我的結(jié)論是：Scala 過(guò)于復(fù)制。它添加了太多的東西，繩子太長(zhǎng)，結(jié)果把自己束縛起來(lái)了。這就是我對(duì)Scala 的顧慮。Fantom 擁有一些很好的功能，而且易于學(xué)習(xí)，很快就可以上手，但是，弱化的類型系統(tǒng)以及幾個(gè)額外類也許還不足以讓它成為下一代大型語(yǔ)言。

所以，我最終還是回到這個(gè)想法——如果Java 是下一代大型語(yǔ)言將會(huì)怎樣？

問(wèn)題在于，添加的越多，再添加?xùn)|西就變得越困難，因?yàn)檫@門(mén)已經(jīng)被填得慢慢的了。不過(guò)，與其跳出來(lái)和Oracle說(shuō)：“讓這門(mén)語(yǔ)言添加閉包；讓這門(mén)語(yǔ)言添加屬性”，假如我們可以為Java做一個(gè)向后兼容版本，將會(huì)怎樣？假如我們提供一款工具，可以將 JDKn+1 轉(zhuǎn)換為JDKn+2，如果你喜歡，還可以在Java 兩個(gè)版本之間轉(zhuǎn)換，你覺(jué)得如何？這是你的向后兼容的想法：你可以在兩個(gè)版本之間進(jìn)行轉(zhuǎn)換。如果是 JKD8 呢？如果不是在JDK8 中使用極客的方式處理閉包和模塊，而是延遲發(fā)布一年，使其向后不兼容，將會(huì)怎樣呢？ 這樣，我們就可以正確地處理閉包和屬性，還有其他一些東西。

實(shí)際上，做減法也是適合的：刪除檢查型異常，刪除一些功能，如：除非是 Nullable 類型引用可為 null。做一些這樣的刪除工作可以帶來(lái)很大的變化。按照這種思路走下去，將會(huì)怎樣呢？

【閱讀推薦】

1. 百家爭(zhēng)鳴 Java需要引入閉包嗎？
2. 再論Java已死 基于JVM的語(yǔ)言已成Java最大威脅
3. 51CTO專訪Scala創(chuàng)始人：Scala拒絕學(xué)術(shù)化
4. 薪酬與權(quán)力 Java之父講述離職Oracle內(nèi)幕
5. Java程序員的未來(lái) 走向混合編程時(shí)代

原文：The Next Big JVM Language     鏈接：http://www.artima.com/lejava