下一代大型JVM语言，下一代jvm

下一代大型JVM语言，下一代jvm

译者注: 原文发表于2010年9月21日，那么对Java的预测以及对其他可能成为下一代大型JVM语言的猜测，到了2013年是否兑现了呢？

周一的JavaOne会议上，我进行了“下一代大型JVM语言”的主题演讲。这个演讲的结论跟我当初开始研究这个主题时预计的并不一致，在这篇文章中会给出我得出的真正结论。

下一代大型JVM语言(NBJL, Next Big JVM Language)

讨论这个话题之前我们先对“大型语言”进行一个定义。我认为，大型语言应该是主流语言、使用广泛、在实际项目开发中大有市场，对行业生态系统支持良好，并有成熟社区支持。另一个可能的定义是：15%的开发人员在某一个特定时期都会采用的语言。基于上面定义，C、C++、Java、C#、COBOL、VB、Perl、PHP和Javascript都是大型语言。当然，读者基于自己的认知可以有自己的看法。不过我们也可以从上面提到的这些语言开始我们的讨论。

接着，我开始研究Java的好与坏。当然，Java必然有它好的一面，毕竟有一千万的程序员选择了它。不过，Java语言也有不好的一面。

谈论Java不好之处似乎不太公平，毕竟这门语言诞生也就15年而已。这么短的时间，就要对它进行历史性的审判，而且Java 1.0中的一些决定在当时看来也是非常合理的，只是放到今天来看，似乎就变成了“我们应该从Java语言中吸取什么教训了”。

从Java中可以学到什么

15年来对Java语言的使用的经验教训总结成下面这些点：

1) 可检查异常。Spring不提供，Hibernate不提供，Java EE也不提供。可检查异常是一个失败的实践（理论可行，实践结果却很糟糕）。这篇博客的读者们或许还对可检查异常情有独钟，但是恐怕是时候“清醒过来”了。几乎所有的主要API提供者都反对可检查异常。如果你还在使用或者提倡使用可检查异常，那么你恐怕已经落伍5到10年了。（我知道这听起来并不让人舒服，但是还在使用的人们，你们真的需要去接受一些现代API设计的思路了）

2) 基本类型和数组。这些设计会保留字节码的底层细节，违反了“凡事皆为对象”原则。泛型无法包容基本类型就是一个经典的例子。比较好的方案是，源代码不用直接使用基本类型或者数组，编译器（或者JVM）来决定是否可以帮你对其进行优化。

3) 任何事物都是一个监听器。在Java和JVM中，每个对象都是一个监听器，意味着一个对象可以和任何另一个对象同步。这在JVM层来讲是非常浪费的。资深JVM调优人员认为，如果放弃对象之间的同步需求，那么还可以对JVM空间和性能进行一些大幅度的改进。（也就是说，会有类似Java 5中Lock这样的类）

4) 静态变量（Static）。静态方法跟普通类方法相比在可复用性和可访问性方面较差。尤其在构造器中的话，经常会导致需要显式的定义接口，从而使得API更加复杂。一个更好的办法就是采用单例对象，单例对象在大多数情况下表现都跟静态对象差不多，只不过也可以像一个对象一样被传递而已。

5) 方法重载。Java语言规范中限制最多的就是方法解析，也就是需要编译器来决定调用哪个方法。解析过程会涉及到父类、接口、可变参数、泛型、封装和基本类型。这是一个非常复杂的算法，而且也不易于扩展。所以应该尽量不去使用方法重载，或者至少在使用方法重载时采用缺省的参数。

6) 泛型。Java泛型本身就很复杂，当使用? exends和? super等变种句型时就变得尤其复杂。非常容易搞错。我们从中学到的教训是Java的use-site variance不是很好用。

当然还有其他可总结的经验教训，但是上面所述是其中的一部分。

NBJL可能包含什么？

回顾历史，我认为下一代普遍可接受语言（next mass-appeal language）中，人的因素应该起到重要作用。

1) 新的程序设计语言中的代码片段应该具备一个典型程序员所希望的适度复杂性。程序员会去期望在每天的工作中使用的语言。

2) 中级程序员认可。所谓中级程序员是指那些普遍对博客、微博或者新语言不感兴趣的人。

3) 程序员可以不用别人的帮助或者接受培训，就能对新的程序设计语言中的代码片段的功能进行合理的准确的推测。

NBJL可以走多远就目前来看是难以下定论的，但是我相信这是一个比较实际的问题。我们所需要的新的程序设计语言能够不需要大规模的培训，程序员们可以快速上手。

在其功能方面，我列举了如下条目：

• 类C的语法（很好用也很熟悉）
• 静态类型（动态类型过于松散并且性能有限）
• 遵循面向对象程序设计（Object Oriented Programming，OOP）思想，并且包括函数式语言的元素（纯函数式言非主流编程语言）
• 易于反射获得（从而避免静态类型限制）
• 属性（getter和setter实在是太让人讨厌了）
• 闭包（捕获循环设计模式）
• Null判断（提供一个判断变量能否为null的方式）
• 并发（好过原始线程和共享可变状态（shared mutable state））
• 模块化（需要考虑更大的单元）
• 工具（希望新语言能够对于工具开发有所帮助）
• 可扩展性（语言的设计具备很好的可扩展性，以支持其上的二次开发，而不需要去修改语言本身的设计）

当然还有其他一些可以讨论的主题-语言设计其实堪比艺术品设计，有太多角度可以观察了。

所以，有哪些语言可以加以考虑呢？

1)Clojure是一个函数编程语言（functional programming language），采用类LISP语法。在处理状态方面很擅长，且其处理方式跟Java语言完全不同。尽管如此，在语法和功能上也跟Java相差太远。

因此Clojure无法成为NBJL。

2)Groovy是一个支持可选类型的动态语言。强依赖于Java，在很多方面都跟Java极为类似，例如语法和代码结构方面。这使得其非常容易上手使用。在脚本和web页面这种需要动态元素和元程序元素（meta-programming element）方面Groovy比较擅长。其动态特性使得对于企业级服务器端核心业务逻辑开发并不是一个好的选择。

因此Groovy无法成为NBJL。

3)Scala是一个OO/函数式语言，采用类C语法。深入研究之后，你会发现其函数特性更为明显。这个特点会促使用户去选择更纯粹的函数式业务逻辑解决方案。Scala采用静态类型，其泛型设计更加具备图灵完备性（Turing complete）。但是，用另外一门语言中的泛型来写程序是否合理呢？如果想要说清楚Scala的所有特性，那还需要一篇文章的篇幅。简单的说，Scala对于程序员来讲束缚太多。尽管第一眼看过去Scala似乎提供了Java梦想提供给开发者的功能，但是一旦深入了解就会发现这是个大坑。Scala不具备成为主流编程语言的特点。

因此Scala无法成为NBJL。

4)Fantom是一个面向对象语言，也包含函数元素，采用类C语法。Fantom在很多方面的方案都简单明了，例如nullable类型，非可变性（immutability）和模块设计。其静态类型系统采用的方式很简单。泛型仅仅在列表（List）、映射（Map）和函数（Function）中得到支持，开发者不能自己添加。在开发者需要添加的时候，Fantom会自己自动进行类型转换。虽然Fantom包含主流语言应该包括的所有特性，但并没有获得相应的关注。其中一个疑问是，Fantom的类型系统足够吸引开发者吗？

在上面提到的语言中，Fantom是最接近NBJL的了。但是其过于宽松的类型系统可能有点让开发者担心，因此也不太可能成功。

个人看来，上面4种语言每种都会教会开发者一些东西。如果你从未了解过函数编程，学习Clojure和Scala会对其有所了解。不管怎么样，NBJL是想选择一个对于所有的开发者所有的开发任务都适合的语言，而且无论是在小型团队还是大型企业项目中。尽管这些语言都各有所长，但目前都无法取代Java。

其他选择

对一千万的Java程序员而言，任何改进都会直接使得这一千万程序员收益。但是目前没有任何一门语言有这个能力。

所以，我们或许应该直接考虑Java？

假如设计一个向前不兼容版本的Java语言呢？

假如这个语言弥补了Java做的不够好的地方（被暴露的基本类型和数组，可检查异常等等）？

假如这个语言不需要正式的培训课程，可以快速上手？

假如有工具可以将旧代码100%准确的转成新代码（反之亦可）？（提供最重要的逆向兼容性）

假如新的语言可以支持闭包和属性呢？

假如仅仅编译模块而非单个类文件呢？

假如编译器/连接器可以决定同一个模块的两个版本在响应同一个调用时执行同一段字节码，因此这可以算是全面兼容了吗？（包括类似模块版本的转换）

假如社区要求Oracle公司来设计一个新的语言来取代JDK8，比如JDK9？（假如新的语言推迟到2013年推出可是可以接受的）

是时候来吸取Java的经验教训了吧？或者让Java来吸收着这些经验教训？

总结

语言总是存在争议的，因为每种语言设计时的视角不同。尽管Clojure、Groovy和Scala从某种角度看来都是非常好的程序设计语言，我还是不同意他们可以成为NBJL。我认为Fantom是最接近于主流语言所需要的静态类型，然而Fantom的简单类型系统以及某些API使得其不利于成为NBJL。

从而，我的结论是：Java最适合成为下一代大型JVM语言，不过是一个逆向不兼容语言。我也认为我们应该接受一个向前不兼容的JDK8在2013年的发布（而非2012年的发布）。

 

英文原文： Stephen Colebourne’s blog，编译：Wld5 - 郑雯

译文链接： http://www.wld5.com/2746.html

【如需转载，请在正文中标注并保留原文链接、译文链接和译者等信息，谢谢合作！】