综述：Scala 是 Java 未来的后继者

作为 Java 未来的后继者之一，Scala 最近受到了大量关注。Groovy 的创始人 James Strachan 和 James Gosling、Charles Nutter 一样，是 Scala 的拥趸，后两人分别是 Java 的创造者和 JRuby 的核心开发者。

James 首先解释了他不喜欢的 Java 特性：

Java 是一个令人惊讶的复杂语言（规范有 600 页，但是有人的确对 Java 的特性心领神会了吗？），表现在它的自动装箱 （在这里隐藏了可爱的 NPE），原生类型，讨厌的数组（它们不是 collection，而且由于缺少多态性，对于通用数据结构和 bean 特性需要很冗繁的 语法，并且仍然没有闭包（即使在 JDK7 中），导致了大量令人烦躁的 try/catch/finally 的语句，除非你使用包含了全新自定义 API 的架 构，但是这样会导致语言更加复杂。Java 甚至有类型引用，不过我们还是不要使用它来存储任何 typing/reading。

尤其是没有 Java7 （即使在 Snorcle 之后它显得更加有意义 - 我想知道 javac 是否会被 jdkc 取代？我猜 javac 已经达到其巅峰；而且闭包看起来不会带来任何的简化或者进步），这个问题表现得更加严重。

他看起来已经被 Scala 深深影响了，尤其是当他说到如果那个时候有可用的 Scala，那么他不会一开始就去发明 Groovy：

老实说，如果在 2003 年就有人给我介绍了 Martin Odersky Lex Spoon 和 Bill Venners 的 Programming in Scala ，那么我很可能不会创造 Groovy。

当然，也有一些 Scala 的特性他不是那么热衷：

对于任何一门语言来说，都有你喜欢和不喜欢的东西。Scala 给我的早期印象的确看起来它在尝试使用一点更多的符号，但是你不需要全部使用。如果你喜欢，你可以仍然使用 Java 风格的 OO。但是我想未来为“特殊物体”使用符号来避免和标识符冲突。

我不是嵌入 import 语句的狂热粉丝，使用 _root_.java.util.List 来区分从相对 import 中得到的“全局”import。我更喜欢子前缀，例如，如果你从 com.acme.cheese.model.Foo 导入，那么导入 model.impl.FooImpl 的时候，我喜欢使用一个相对前缀，也就是说，导入 _.impl.FooImpl 将会使事情简化，而且和 Scala 在 简化和删除冗余代码（导入 java.util._ 是多种类型的）保持一致。

任何时候和 Java 相比， James 都认为 Scala 好太多了：

Java 的不足可以比作大量的毛疣，那么同样在 Scala 中，这些地方正是表现了 Scala 的美、简化和强大。

Adam Bien 在他的博客中指出，即使是 Java 之父 James Gosling，看起来也是对 Scala 喜爱有加：

在一个社区（java.net booth）举办的和 James Gosling 对话会议上，一个与会者问了一个非常有意思的问题：“除了 Java，现在你会把哪种语言运行于 JVM 之上？”。答案是惊人地快速简洁：Scala。

Charles Nutter，JRuby 核心开发者，他也认为和 Groovy 和 JRuby 相比，Scala 更可能替代 Java ：

我必须说 Scala 看起来是是现在 Java 王座的继承人。其他在 JVM 的语言看起来不可能有 Scala 那样的能力来取代 Java，Scala 背后的推动力是无可置疑的。Scala 还不是一个动态语言，但是它有许多流行动态语言的特性，例如它的灵活富类型系统，稀疏和简洁的 语法，函数式语言和面向对象范式的完美结合。Scala 的缺点：“太复杂”或者“太丰富”，但这些可以通过编码规范很好避免，从而构建更健壮的编辑器和工 具，以及指导多语言开发者明白如何更好地使用 Scala。Scala 是 JVM 上静态语言的重生，它也像 JRuby 那样延伸平台的性能，这些都是 Java 做 不到的。

Scala 现在已经是今年 JavaOne 的一个主题，有一些相关的议程，而且在大会的最后一天甚至会有一个开放的讨论。

你怎么想呢？Scala 是不是在将来最合适取代Java 的语言？或者， Java 是最后一门巨型语言（LBL）？

查看英文原文： Roundup: Scala as the long term replacement for Java