【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
