關于下一代大型JVM語言的思考
原創【51CTO 9月27日外電頭條】我們曾不只一次的提到基于JVM的語言正在開始流行，Java程序員和Java平臺本身正在走向混合編程時代。目前，基于JVM的語言有Scala、Groovy、Clojure等，但這些語言哪一個會成為未來JVM上的主力？
近日在舊金山舉行的JavaOne 2010大會上，OpenGamma的技術工程師兼Joda Time開源API項目組長斯蒂芬·科爾伯恩與Artima主席比爾·文納斯就“下一代大型 JVM語言”展開了一場對話。在這一對話中，史提芬表達了對于下一代大型語言的思考。
你認為哪種語言將成為下一代大型JVM語言？
首先，我認為，想一想 Java 給予我們的教訓對這個問題是有幫助的。Java哪里做錯了？哪里做對了？以后我們要怎么做？在這種語境下，其他主要的替代語言（Groovy, Scala, Clojure、Fantom）是否有可能成為下一代大型JVM語言？
那么，我們從 Java 得到的教訓是什么？如果我們可以重新來過，我們會回避許多東西，如暴露的基本數據類型（exposed primitives）、暴露的整列以及檢查型異常（checked exception），我們不會把這些東西放到語言中。
然后，是一些我們想要在新語言中實現的東西。很明顯，一種更優秀的模塊化方案是其中之一。但是，Java 中的模塊化，我們一直在說這事，并不是真正我們想要的。事實上，我們可以不再編譯至類文件，而是只編譯至模塊。編譯器不再輸出類文件，而只輸出模塊。我們有時可以在模塊系統中添加一項行得通的功能，確定版本 1.1 是否與版本 1.2 兼容。模塊系統檢查所有我們所用的方法的字節碼，并作出判斷， 因為你所用的全部方法的字節碼沒有變化，因此 1.1 和 1.2 對于你來說是完全兼容的。雖然還有好多事需要做，但是有些這些事情需要一點反思。
現在，我們有4 門主要的語言可供選擇：Groovy, Scala, Clojure、Fantom，這些語言怎么樣呢？
Clojure所用Lisp語法。這對Java開發者帶來了很大的困難，所以，看起來它不可能成為下一代大型語言，即使它有一些很棒的創意。
Groovy是一個不同的小語種，它在功能方面填補了Java對于腳本語言的需求。構建腳本方面，Groovy將會扮演一個角色，尤其是結合 Gradle。也許在web應用程序方面也會有重要的作用。
其他兩門語言：Scala 和Fantom，有些類似，他們都是靜態類型的，但他們處理類型系統的方式完全相反。從某種程度上，Scala 已經一路奔向類型系統了；如果我理解的沒錯，你可以在Scala 泛型內作出一種圖靈完備性（Turing-complete）的語言。更多關于Scala語言的介紹可以參考51CTO專題：Scala編程語言。
Fantom 走向了另一個方向，弱化了類型系統。對于這兩種語言，我的結論是：Scala 過于復制。它添加了太多的東西，繩子太長，結果把自己束縛起來了。這就是我對Scala 的顧慮。Fantom 擁有一些很好的功能，而且易于學習，很快就可以上手，但是，弱化的類型系統以及幾個額外類也許還不足以讓它成為下一代大型語言。
所以，我最終還是回到這個想法——如果Java 是下一代大型語言將會怎樣？
問題在于，添加的越多，再添加東西就變得越困難，因為這門已經被填得慢慢的了。不過，與其跳出來和Oracle說：“讓這門語言添加閉包；讓這門語言添加屬性”，假如我們可以為Java做一個向后兼容版本，將會怎樣？假如我們提供一款工具，可以將 JDKn+1 轉換為JDKn+2，如果你喜歡，還可以在Java 兩個版本之間轉換，你覺得如何？這是你的向后兼容的想法：你可以在兩個版本之間進行轉換。如果是 JKD8 呢？如果不是在JDK8 中使用極客的方式處理閉包和模塊，而是延遲發布一年，使其向后不兼容，將會怎樣呢？ 這樣，我們就可以正確地處理閉包和屬性，還有其他一些東西。
實際上，做減法也是適合的：刪除檢查型異常，刪除一些功能，如：除非是 Nullable 類型引用可為 null。做一些這樣的刪除工作可以帶來很大的變化。按照這種思路走下去，將會怎樣呢？
【閱讀推薦】
- 百家爭鳴 Java需要引入閉包嗎？
- 再論Java已死 基于JVM的語言已成Java最大威脅
- 51CTO專訪Scala創始人：Scala拒絕學術化
- 薪酬與權力 Java之父講述離職Oracle內幕
- Java程序員的未來 走向混合編程時代
原文：The Next Big JVM Language 鏈接：http://www.artima.com/lejava
