Java的未来：百家争鸣的JVM

【51CTO独家特稿】2010年开发界最值得期待的一件事就是Java 7的正式发布（如果Sun，或者说，Sun-Oracle能够遵守他们在2009年Devoxx大会上做出的承诺的话）。无论Java开发者们是否喜欢，这个从四、五年前就已经开始酝酿、并且经历了数次延期的Java 7是Sun与Java开发者社区高度协作的成果，其重要性是不可忽视的。然而根据我们的了解，Java编程语言在此次更新中的改变是极其有限的（参考阅读：Java 7新特性展望。值得一提的是，文中提到的闭包最后还是被加入进了Java 7的日程当中，不过开发者们的反映似乎没有Sun预期的那么热烈）。那么，这次重大的变革都发生在哪些方面呢？

Java，JDK与Java SE

首先我或许应该先解释一下：Java 7这个用语其实并不严谨，准确的说法应该是JDK 7或Java SE 7（Java产品的命名规则一直以混乱著称，不过基本上我们可以认为Java SE等同于JDK。这在JDK的官方下载页上是可以证实的）。那么，这个JDK包括了哪些部分？请允许我借用一下JRuby核心开发者之一，Ola Bini在一次演示上用过的简图：

 

图中的JVM即Java虚拟机（在Java SE中特指Sun的HopSpot），API即Java语言API类库，Java Language即Java编程语言。确切的说，鉴于用JDK开发Java程序的开发者们是自己写的代码而此代码并非是随JDK附送的，此处的Java编程语言理解为javac（编译器）更加合适。

当然，JDK比上面这张图要复杂的多。感兴趣的读者们可以研究下面这张图进行进一步了解：

 

Java的强大与成功

我们都知道，Java代码的处理方式是先由javac把代码编译成JVM看得懂的字节码，然后JVM就好像解释器一样把这些字节码执行出来。因此，无论是怎样的平台，只要上面有合适的JVM就能跑Java程序，这促成了其“编写一次，到处运行”的特性。这成为Java强大——因而成功——的重要原因之一。（当然，这是一个理想化的境界。出于技术因素以及不同平台上的JVM成分复杂的关系，“编写一次”之后要“到处运行”往往仍会需要一些代码的改动。）

除了跨平台特性之外，Java的成功还有很多其他因素，下面选取了几个比较有代表性的观点供读者们参考：

◆完全的面向对象——甚至连字节码都保持着对象结构

◆完善的类库

◆自身携带的线程类库可以进行多进程处理

◆自身携带很多网络功能类库

◆JVM中的垃圾回收器（GC）可以进行自动内存管理

◆编译+解释的双重步骤和GC机制等因素提升了安全性

◆JVM的性能还不算糟糕，随着JIT编译等技术的出现还越来越好

其他语言的进驻

JVM上最初只运行Java代码。不过由于其运行机制，如果通过“特制”的编译器将用其他编程语言书写的代码编译为Java字节码，那么非Java代码也可以运行在JVM之上。编者目前还没有考察出第一位登陆JVM的非Java语言是谁以及确切的登陆时间，然而对于1995年诞生的Java，JRuby的另一位核心开发者Charles Nutter曾经在08年评论说：“几乎每一个超过五岁的编程语言都或多或少有自己的JVM运行版。”下面是这个列表的一部分：

 

那句广告词是怎么说的？哪个餐馆吃饭的人多，那个餐馆的饭菜一定差不了。那么，JVM这个餐馆究竟好在哪里？

其实在上面介绍的Java成功的因素中，有三条都是与JVM相关的，即它的垃圾回收机制、安全性以及性能。事实上这也差不多概括了所有JVM的好处了。在性能这一点上或许有待商榷，不过自从JIT编译技术应用在JVM上之后，据说其性能已经接近了C++的级别；而在JDK 7当中也承诺会有性能的大幅提升。另外，JDK 7即将使用的全新垃圾回收器G1也承诺将带来更好的并发性、可预测性以及性能。

据Java之父James Gosling使用过的一个统计，世界上有超过8亿5千万台桌面设备启用了Java（即，至少安装了JRE），还有100亿台具有Java功能的设备。JVM这样一个质量好名气又大的舞台，谁会不想上去跳几步？

Java语言的衰老

在这些进驻JVM平台的语言中，有好几个都是专门定位于JVM的新语言（而非其他现成语言的JVM版本），其中以Clojure、Groovy和Scala为代表。而这些语言的创始人们都不约而同的表示过自己对Java语言的厌倦与失望。Clojure的创始人Rick Hickey说：“我想要一个动态的、富有表达力的、函数式的语言。”Groovy的创始人James Strachan说：“Java是一种令人惊叹的复杂语言，它的语法规范长达600页，我怀疑到底有没有人能真正理解它。”James在去年的一篇广为流传的博文中表达了自己对Scala语言的看好，而Scala语言的创始人Martin Odersky则是这样描述Java的：

“经过Pizza和GJ的经历，我有时会感到沮丧，因为Java是一个具有非常强的约束的语言。因此，很多事情都不能像我想象的那种方式那样去做——那种我原本确信是正确的方式。……其中最强、最难以应付的是，它必须充分地向后兼容非泛型Java。”

在09年7月的51CTO编程语言排行榜上，red7对Java语言的弱势进行了一番总结，观点如下：“……Java的进化速度在最近几年已经远远无法追赶日趋复杂项目需求和苛刻的交付日期。人们开始尝试各种开源项目以缓解Java在某些方面的不足，以Hibernate和Spring为代表的框架快速发展和普及；另一方面，Sun和JCP的各种标准不断遭到人们的质疑，JSF和JPA等官方框架被大多数开发者抛在一边。而这背后，是Sun和JCP对新需求的麻木和对社区的漠视，这直接导致Java的更新落后于变化，Java正在新变化新需求中变得缓慢和老态。”至于更加具体的方面，Java程序员、架构师，LambdaJ的作者Mario Fusco的这篇博文对Java语言特性的老化进行了全面的总结。

衰老中的Java语言王者之风犹存，但既然JVM是一个如此优秀而开放的平台，由更加年轻、功能更加强大的语言来承接JVM这个舞台，相信也是Java愿意看到的。事实上，Java之父自己也清楚的表述了这个观点：“我们看中的并非Java语言，而是JVM。事实上我们可以让所有语言一起工作。”同时，Sun自己也在2008年初启动了一个叫做Da Vinci Machine（达芬奇机器）的项目，试图让JVM更好的支持所有动态语言。而这个项目的一个重要组成部分，JSR 292（Java平台的动态语言支持），也将在JDK 7当中实现。如果成功的话，动态语言在JVM上的性能会得到飞一般的提升，甚至可以和Java语言本身相媲美。

我们需要怎样的语言？

无论Java语言的支持者们是如何反对这种在他们看来有些舍本逐末的行为，事实正在逐渐证明这个推送JVM的方向是进步的，而且是受开发者们欢迎的（比如Groovy的开发者们大多都表示庆幸自己从Java投向了Groovy，并且翘首期待JSR 292的到来）。这是一个开放的时代，语言的好处和语言的糟糕之处都可以轻易地飘到那些项目经理的耳朵里，而接下来，项目经理的下定决心只是一个时间问题。

那么，项目经理们需要什么？或者说，以后的企业级项目和Web项目需要怎样的语言？一般而言，有下面几点：
◆可伸缩性
◆可移植性
◆并行编程
◆高性能的
◆DSL（领域特定语言）的实现

当然还有对于低风险的要求，比如与旧项目的兼容性，旧项目迁移的成本，开发工具的支持，开发团队对语言的熟悉情况，以及语言开发团队的稳定性等等。而具体到每一位开发者头上，那么情况变得更加复杂。他们可能想要：
◆动态的
◆静态的
◆强类型的
◆函数式的
◆富有表达力的
◆面向对象的
◆简洁的
◆容易理解的
◆容易学习的（在有Java或其他语言开发经验的基础上）
◆深刻的
◆快捷的
◆模块化的
◆灵活的
◆有强大的类库
◆有好用的框架
◆有合适的IDE
◆有活跃的社区
……

某些语言能够满足上述条件中的很多条，但是很明显，没有任何一种语言能够满足所有的条件！同时，同一个项目的不同层面的需求也是不同的。现在全世界最流行的微博服务Twitter，表层是Ruby on Rails，底层是Scala，而Twitter团队进行这样的选择正是因为考虑到不同层面的业务需求。

事实上，这种多语言编程(Multi-lingual programming)，或者叫做混合语言编程(Polyglot Programming)并不是一个新概念，这个理念的成功案例可以追述到二十多年前，当时诞生的而至今在开发者社区中仍然火热无比的Emacs正是一个C语言与Lisp方言的混合产物。对于多语言编程适用的层次，请允许我再次借用Ola Bini的一个预言，在预言中他描述了同一个项目中可能会需要不同语言的三个层：
◆稳定层（stable layer）–不包含大量的应用程序功能，可以使用静态语言构建
◆动态层（dynamic layer）- 包含大量的应用程序功能，使用动态语言构建
◆领域层（domain layer）- 包含大量的应用程序功能，使用DSL构建

Twitter这样的成功案例刚好支持了这样的预测，因为Scala是一个强大的静态语言，而Ruby不仅是一个动态语言，还是一个十分适合编写DSL的语言。

百家争鸣的JVM

不过话又说回来了，既然混合语言编程这么好，为什么一直以来都没怎么流行呢？答案很简单，和我们与国际友人之间有沟通问题的原因是一样的：一段Ruby代码要如何明白一段Java代码说了些什么呢？对于高级语言来说，要互相理解对方的功能，进而进行交互，是一件很困难的事情。如果无法交互，又要如何一起来完成同一个项目呢？

沟通问题是一个很大的障碍。然而，这个障碍的清除早就有了一个成功的案例：那就是微软的.NET平台。在微软官方文档的描述中，这种“沟通”被命名为“跨语言互操作性”，或者“语言互用性”。在.NET平台上，这个问题的解决方案是公共语言规范 (CLS)。事实上，不得不说微软在这方面做的要远远超过解决“沟通问题”的这个层面：它的目的是能够让多种语言可以自由共享和扩展彼此的库。不过，在过去的很长一段时间内，.NET平台上的主要公民只有两个：C#和VB.NET，其他公民则大多半死不活，这使得这个互操作性的意义大打折扣。

然而JVM现在的情况似乎非常乐观：且不说Groovy、Scala这种专门针对JVM而创建的语言活的挺滋润（这两个语言都可以直接使用Java类库，据说是所有的），就是移植到JVM上的语言，尤其是JRuby和Jython，看起来活的都不错，足以让它们在面对IronRuby和IronPython的时候高兴的挺起腰板。

 

• JDK核心工程师答疑：模块化令JDK 7不再..
• 漫谈Java理念的转变与JVM的五大优势
• 漫谈JVM的基本垃圾回收算法
• JDK 7一再延期的背景披露以及OpenJDK的..
• 有关JVM处理Java数组方法的思考

为什么.NET在多语言之路走了很久的路仍然青黄不接，而JVM已经俨然呈现出一幅百家争鸣之态？答案很明显：因为Java是开源的！（准确的说，那些语言开发者们需要掌握的部分都是开源的，而开源社区的创造力显然要远远超过微软那虽然不算少但仍然精力有限的开发团队。）语言互操作只是第一步，随着开放理念的前行，平台的互操作，标准的互操作都将逐步跟进，届时Java的开源性质将使JVM上的百花绽放的更加鲜艳，而混合语言项目则会发现Java平台是他们最理想的去处。

 

结语

综上所述，软件项目的未来在于混合语言编程。此前景的舞台将在未来数年内搭建成熟，而聚光灯的焦点就是一个百家争鸣的JVM。观望此番前景，我们在近日的51CTO Java频道改版中特意新添了一栏目，名为Java+，目的正是观察基于JVM的混合语言编程的发展趋势，为Java开发者们提供指引。想一想看，当你的老板或项目经理决定要尝试Groovy或是Scala进行部分开发的时候，如果你能够立即站出来为他进行一些解惑或指点，那么你又何愁饭碗随着Java语言的老去而消逝呢？

现在就开始学习吧。

你未来可能会用到JVM上的哪些其他语言？你是否已经在学习、使用这些语言，或者计划学习这些语言？谈谈你的看法吧。