郑晔谈Ruby on JVM和XRuby

个人简介 郑晔，ThoughtWorks中国公司咨询师，开源项目XRuby核心成员，目前正致力于让Ruby更好地运行于JVM平台。他的Blog为：http://dreamhead.blogbus.com/

   

1. 我们请今天被采访的对象郑晔来做一个简单的自我介绍，郑晔你今天为什么坐在这里？

大家好，我叫郑晔，我是ThoughtWorks的咨询师，现在主要的工作是在Ruby on JVM这个方向上，我个人是XRuby的主要的一个开发者，今天坐在这里主要是和大家探讨一下关于Ruby on JVM的一些话题。

   

2. 对，你提到一个词Ruby on JVM，那我首先想了解一下，什么是Ruby on JVM，或者说为什么我们要把Ruby放在JVM上去运行？

正如你刚才提到的，Ruby on JVM就是说把Ruby放到了JVM上，有时候换句话说，在JVM这个平台上我们可以去运行Ruby，那谈到为什么会把这个Ruby放到JVM上呢？可能很多人,就是最会奇怪的这一点就是，Ruby有自己的平台,它为什么就会放到JVM上？实际上,我们已经知道，就是通过大家的实践可以已经知道，Java本身是一个已经被大家广为接受的一个平台，我们已经有很多人非常熟悉这个Java的这些知识，所以说Java这个平台本身已经得到了大家的一个认可，如果说我们在开发的时候把Java这个平台去抛掉，对现在的开发者来说，这是一件不可能的事情。

   

3. 我觉得有意思的反而是另外一方向，既然Java已经是一个成熟的平台，为什么Java的开发者要来关心Ruby呢？他们完全可以在他们自己的世界里活的很好？

这是个很有趣的话题了，Ruby可能现在受大家所关注的就是可能通过这个Ruby on rails就是有一个崛起，而Ruby on rails带给大家的是什么呢？就是说一些开发效率的提升，大家可能经常听到的是一些关于Ruby on Rails可以给开发带来十倍的开发效率的提升，那所以说，即便抛去这个广告因素来说，可能也确确实实有几倍的一个提升。那人们总是愿意用这种最少的力量去干尽可能多的事情，那既然有一个像Ruby这么好的一个平台的话，那么人们也更多的希望能把Ruby运用在自己的实际的工作之中。那我们如果有这样的一个机会，如果把Ruby这样好的一个平台，在像Java这样一个比较成熟的平台上，两者结合起来的话，能把二者的优势结合起来的话，就是对大家来说也是一个非常好的选择。

   

4. 那么你能不能具体介绍一下这样做能够带来哪些好处呢？

主要的从我们现在可以看到的一些情况来说，我们就可以把一些Ruby的优点和Java的优点结合起来。那Ruby的优点是什么呢？Ruby的优点就是它开发效率高，而Java的优点就是它资源非常丰富，我们都已经知道，在企业级应用里边的一些运用，我们已经有大量的JavaEE方面的应用服务器可能在某些问题上有大量成熟的一个解决方案，那这样的话，我们就可以把这些优势的东西结合起来。那意味着什么？如果我们可以把Ruby放到JVM这个平台上，那我们就可以，比如说在我们的Ruby的代码里去使用Java的类库，我们已经知道这个Java已经有很多现成的，做得很好的类库或者解释方案，我们都可以在Ruby代码中得到复用；另外一方面，我们如果可以把Ruby和Java平台结合起来，那就意味这我们可以把Ruby的应用部署到JVM上，那这个点又意味着什么呢？就是说我们可以有很多人，现在比如说有很多企业它已经买了Java的一些应用服务器，那如果是，对它来说如果它们要推翻自己之前所做的那一些，把以前用到的Java服务器全给抛弃了，对它们来说是一种非常非常大的浪费。而如果可以把Ruby放到JVM上，我们既可以利用到Ruby高效的开发效率，又可以把它这个应用部署到像大家已经购买的这个JavaEE的应用服务器上，那它之前的这个投资就可以得到一个重复的利用，这样的话可以更好地帮助大家去接受Ruby，也可以更好地让大家之前的投资得到一个重复的利用。

   

5. 听起来就像是把一个Rails的运用打成一个War包放到J2EE的服务器上？

对，这是我们将来工作的一个主要方向，就是希望能把这个普通的一个Ruby应用或者是一个Rails的应用打成一个JAR包，或者EAR包、或者WAR包，直接部署到JavaEE的应用服务器上。

   

6. 如果我们要把Ruby放到JVM上运行的话，做这件事情的方法有哪几种？你们现在看到的？

这个可能是需要从语言的角度来剖析一下，可能大家也都知道Ruby是一门解释性的语言，那可能最常见的方式就是说把Ruby的这种解释性，利用Java去开发一个Ruby的解释器，然后让这个Ruby的应用可以跑在JVM的平台上，而这也确确实实是现在可能比较主流的方式，可能是JRuby做，就是我们知道有一种Ruby on JVM的一种实现——JRuby,它所作的一个工作；那另外一种方式，我们除了解释的话，我们还可以采用编译的方式，把Ruby的代码编译成Java Bytecode，然后让Bytecode去运行在JVM的平台上,这是我们现在看到的主要的两种工作方式。

   

7. 你刚才提到的两种实现Ruby on JVM的做法——编译和解释，作为我不是计算机专业出身的程序员，我对这两种方式了解的还不够深入，你能不能解释一下它们的主要差别在什么地方？

我们可能知道就是语言变成可执行的方式，实际上就是从原代码去通过解析，然后转换成另外一种格式，然后去执行它。可能解释和编译的差别就在于它们执行的方式不同，这就决定，实际上为什么会有这种不同呢？事实上就是它们编译生成的中间产物不同，对于解释的方式来说，我们可能编译产生的是一个中间的语法树，然后通过编译这棵语法树的方式，然后去解释进行，这样的话，我们就需要基于我们原始的平台之上，上面建立起一个新的平台，来专门用做这个语法树的一个解释引擎；而对于编译的方式，我们直接去把它需要编译成，比如说对于JVM来说，我们就可以直接把它编译成字节码，而这个字节码就可以直接运行在这个JVM平台上。就这样的话，二者之前就是存在一个小小的差异，就是说对于解释的方式中间需要构造一层，一个解释引擎出来。而对于编译的方式，它相当于是可以直接运行在这个底层的平台上，这就是为什么我们会说二者之间会有一些性能差距，因为显而易见，解释的方式多了一个中间的层次，所以它的性能上要略微差一些。

   

8. JRuby是采用解释的方式实现的吗？

JRuby最开始是通过解释的方式实现的，是通过直接将CRuby的一个实践移植成Java的代码，而现在的JRuby实际上是一种混合方式。JRuby现在已经在开发自己的一个编译器，但是这个编译器目前来说，还不是很完整，所以它现在所能做的，如果这个代码可以编译执行的话，它就会把这个代码在缺省的方式下编译成字节码。而如果这个代码无法编译的话，它会回退到这个解释执行的方式，所以它是一种，实际上它是一种混合的方式，它们那部分能把代码进行编译的部分，它们自己称之为JIT,就是类似于我们在Java中经常听到的那种JIT的方式，就是说我们可以把它变成Java，类似于Java本地的字节码一样。

   

9. 对于这部分我有两个问题，第一个问题就是JRuby是不是在性能上遇到了严重的问题，以至于它们现在要去考虑编译的这条路？

这是肯定的，因为很多人可能止于Ruby，包括JRuby在内，就是因为它们的性能。而实际上我们也知道，CRuby本身就性能不好，而JRuby是把CRuby这种性能不是很好的做法给移植到Java上，造成性能进一步下降，所以现在目前为止，JRuby就遇到了很大的瓶颈，这也是它不得不转向这个编译的方式。

   

10. 对于你刚才所说的性能不好，你能不能举出例子或者说数据，来给大家讲一下，它到底不好到什么程度？

如果大家有过了解的话，可能会知道前一阶段有一个，各个Ruby之间做一个Benchmark的性能对比，在那个结果上来看，当时的JRuby的性能，JRuby慢的速度大概是CRuby实现的一个十几倍，换句话说，本身就已经很慢，被大家所抱怨的一个CRuby，那JRuby还要比它慢上十几倍，这就是一个很可怕的事情了。

   

11. 你能不能做一个横向的比较，告诉我们你刚才所说的性能差到底是一个什么情况？

我通过自己的了解的话，知道有一个对比，就是把Python和CRuby放在一起对比，大概Ruby的性能大概只有Python的60%左右，而你可以想象，即便是这样的一个性能，仍然是JRuby现在性能大概在十几倍，那可见JRuby的性能要差到一个什么样的程度，这也是可能为什么要在Ruby on JVM这个平台上，做大量优化的一个原因。

   

12. 现在所做的优化，你看到它起到什么明显的效果了吗？

这样就不得不提到，我自己个人正在所从事的项目叫XRuby，这是一个Ruby语言到Java Bytecode的一个编译器，通过自己的实测呢，就是大概，我们的性能可以达到和CRuby一样好，甚至比CRuby更快，如果抛开一些可能的标准库实现的影响来说，大概能接近于CRuby二倍的一个样子。

   

13. XRuby取得这么明显的进步，你想不想介绍一个这个XRuby中间的一些细节的东西？

实际上，XRuby和JRuby之间的差别主要在编译和解释，XRuby从最开始，XRuby的出发点它就是一个编译器，所以它没有中间的像JRuby一样中间建立一个解释引擎，而是直接把编译生成的代码运行在JVM平台上，所以它可以达到非常高的一个性能。

   

14. XRuby这个项目它是怎么发起的呢？现在的团队有多少成员在里面？

是这样，XRuby是去年九月份，有这个项目的发起者，他的网络的ID是Yawl。它把这个项目，从原来的自己开发的一个业余项目正式移到这个Googlecode上，变成了一个开源的项目，而我就是在这个时候，加入到这个项目里，经过一段时间的开发，我们大概隔了三四个月，在2007年1月份左右，我们发布了第一个版本。随着这个版本的发布，可能越来越多的人，关注到XRuby，越来越多的人加入到XRuby这个项目之中，和我们一起共同探索Ruby on JVM上一些有趣的问题。

   

15. 现在XRuby它的目标是什么？

XRuby从起步开始，它的目标其实很简单，就是为了乐趣，我们刚开始做的时候，并没有考虑我们到底通过这个项目要获得什么，或者要得到什么。只是因为大家对Ruby，对编译器，有自己的爱好，有自己的乐趣，所以我们建立了这个项目。有人建立了这个项目，有人参与了这个项目，但随着这个项目逐渐的发展，可能越来越多的人关注它，我们也更多的开始考虑，XRuby会给大家带来一些什么，会给社区带来一些什么。现在来看，这个XRuby为Ruby发展指出了一条，可以说是指出了一条路——编译这条路。这样的话，有了这条路的话，我们可以很好的解决Ruby在开发中遇到最大的问题。Ruby被人置疑最大的问题就是性能问题，在这条路上走下去的话，如果是编译的方式，可以很好地解决Ruby开发的性能问题的话， Ruby可能会得到大家更广泛的接受。通过这条路，让更多的人认识到Ruby是一种很好程序设计语言，让更多的人在实际的开发中使用Ruby。我相信这个对Ruby的发展很有好处的。

   

16. 既然大家有很多人是因为Rails而了解Ruby的，那么我想XRuby一个比较近的目标就是支持Rails？

没错，我们很早就希望把Rails能运行起来，这也是可能有一些，比如说我们要把这个Rails应用部署到JVM这个JavaEE的服务器上可能必须要做的一些事。从我们自己制订的这个规划来说，我们可能是希望，能在年底的时候，把这个Rails应用部署并能完全编译成这个Bytecode，然后部署到应用服务器上。

   

17. 现在XRuby进展到什么地方了？

现在是目前为止，能可以运行一些0.2版本的Milestones，可以运行单元测试框架，我们可能下一个版本的Milestones是0.3，把随Ruby自带的这些单元测试全部通过了，这也是我们最近期的一个目标。

   

18. 据我所知，Rails的框架设计里面用到了很多的Ruby特有的语法，那么XRuby在支持这些语法的时候有没有遇到困难？

确实，在开发的时候我们遇到了很多困难，包括Runtime整体结构的搭建，或者有一些很特殊的用法。实际上现在可能开发中，有一些难点也是为了解决特别的一些地方，这也是可能有一些受到阻碍，项目受到阻碍的原因。因为毕竟它是一个静态语言和动态语言的一个不同，我们虽然已经在这个JVM平台上建立起一个动态语言的支撑结构，但是说如果想完整地使用Rails应用，或者Ruby应用的话，那可能需要做的工作还有很多，我们希望年底之前把这些工作尽可能地都解决掉。

   

19. 你提到静态语言和动态语言的不同，那么，我希望你从更加技术的角度来解释一下，这个不同到底是一种本质性的冲突还是一些细节的问题，解决它的难度究竟有多大？

静态语言和动态语言实际上来说，如果从纯最底层的计算机角度来说，它们是完全可以统一的，但是说，可能在实际的应用中，它们已经完全分开了，比如说像Java这种程序设计语言，它很多东西，就已经编译时就固定好了。而对于像Ruby这种语言的话，它有很多东西，包括我们也知道Ruby的一些特性，它的类是可以动态地添加一些方法进去或者删除一些方法的。这样的话，我们必须得建立一个，用来支撑这个动态语言的一个结构。最简单的一个例子，如果往方法里添加结构，可能在Java程序里边，它可能就会被编译成类似于虚拟表的结构，所以每一个方法的位置都是固定的，你不可能在运行时去添加。而在Ruby里边呢，为什么可以去添加呢？可能它实现的，只是一个名字和一个方法的一个对应，而这样的，就类似于这种Key Value的，可以简单把它放到一个哈希表里，这样的话，你通过这个名字就可以找到对应的应用，而这个哈希表本身，就是不封闭的，你就可以在程序运行的时候，动态地向里边添加东西，这就动态语言和静态语言的可能，从表面上看来一个比较浅的区别吧。当然可能具体实现的时候，某一些点，比如说，如何去访问Java的一个堆栈的问题，因为Ruby在里边，我们可能，比如说我可以去访问一个方法的局部变量，在Java里边，我们如何去把这个关系对应到我们这个实现里面，可能有不同的人会有不同的方法。比如说，我们把它放到一个，每次每调用一个方法，我们把这个局部变量的信息放到一个表里，或者说，关键就是我们不仅仅要做一个能完成功能的结构，我们还希望能做一个高效完成的结构，可能这才是，真正挑战的一点。我在做好一项功能的前提之下，而且不损失性能，这是很难的，这可能我们在开发中遇到的，一个比较困难的一个点。

   

20. 另外一个问题是，Ruby的程序里面，大量地会用到本地扩展，这些很多是用C来编写的，那么XRuby或者说其它的Ruby on JVM的实现怎么解决这个问题？

这确实是个问题，目前为止还没有人给出一个非常非常好的一个解决方案，我们当然也想过，包括方式用JNI的方式，包括等等。但是目前为止，还没有一个让我们非常非常满意的一个结论，如果哪位朋友对这方面有兴趣，可以参与到这个开发过程中来，可以提出你们的解决方案，我们也希望这个问题得到一个非常好的解决。

   

21. XRuby和JRuby在我听起来，都在开始做编译器方面的工作，你不觉得这是一种重复发明轮子的工作吗？为什么你们没有把这个工作合并起来？

怎么说呢，其实说XRuby在刚开始做编译器的时候，JRuby还没有做这份工作，所以说XRuby准确来说在编译器这个方向上是先走了一步，所以说XRuby在编译器的支持上，要比JRuby完整得多。而JRuby的好处在哪里呢？它有一个相对完整的一个整体的实现，比如说它的Building类库和它的解释器都比较完整，现在一个好的一点就是，XRuby和JRuby会互相，目前为止，会互相把它们好的东西借鉴给对方，比如说有可能我现在正在做的一件事，从JRuby上借鉴了一些动态的代码生成的机制到XRuby里边，这样就可以简化代码的一个编写。再比如说，可能我前期，帮着JRuby的Team去做了一些工作，把这个一些，比如说像Method Cache之类的一些东西移植到JRuby中，这样的话，双方会把自己互相好的一方面去互通。在我看来，其实XRuby和JRuby的一个差别在于，JRuby可能面向的更多的是，现在来说面向的更多的是更广阔的一个面，XRuby实际上给大家提供了一个非常非常好的一个实验平台，你可以通过这个XRuby这个平台去做更多的一些事，可以去实现你更多的一些想法，所以在XRuby的这个，我们有一个Todo-list里边有一项叫Wild Idea，你可以把一些非常狂野的想法在XRuby平台里边实现了，这是我觉得是，二者可能很大的一个差别的地方吧。

   

22. 现在在.NET平台上也有实现Ruby的计划，包括Ruby CLR，Ruby.NET，那你觉得，这所有的这些项目，它们会不会在未来共同抽取一些通用的东西？

恩：会有，可能会有。你包括像XRuby它为什么前边用的是X，这个最开始，这个项目的发起者聊到这个项目的时候，就是说，这个X代表的不仅仅可能是为Java平台，可能将来也是为.NET平台，当然可能是因为最初也没有预想到这个，工作量会有如此之大。现在可能主要的工作，都是在Java平台上，我看，实际上.NET平台上的一个实现和这个Java平台的实现，可能有很多共同的地方，包括像前端，包括一些实现的机理上，它们都是有一些可以互通的地方，所以，我觉得像这些平台之间可以互相的交流，互相的讨论，也许正如你所说的，我们可能给它们找到一些共通的地方，共同的路或者共同的基础结构之类的。

   

23. 那我很好奇，开发一个编译器是不是一件很酷的事情？现在你做的事情里边，有什么很酷的想跟我们分享一下？

可能很多人都认为开发编译器是高级的事情，我作为自己的一个个人爱好来说，可能对于语言的实现来说，特别有兴趣，所以这个可能是当时，我为什么选择加入XRuby的一个重要原因。在这个开发过程中呢，有很多，确实有很多很好玩的东西，就是包括你对，就是通过比如说像我开发的这个Runtime的部分，你可以对程序，为什么这样运行，有一个自己，你可以清清楚楚看到程序为什么会这样运行，你可以对程序有一个很好的理解，可能帮助你将来，可以写出一个更好的程序。说一件比较酷的事情，聊聊最近在做的一件事吧，大家可能知道，这个Ruby里边，就方法调用可能刚才我说了，比如放到一个哈希表里，但是取出来怎么调用呢？如果方法和参数不一样的话，怎么办？可能最简单的方式，或者打成一个数组，或者打成一个包之类的，就整个给它送过去。但是实际上，我们会发现，有大量的方法调用可能只有一个参数，或者是没有参数，那我们可以针对它去做一些优化，这样的话，你的程序的性能，你不需要在运行过程中，打成数组那个包，然后你直接可以去调用它，当然它性能还得到了一个极大的提升。而可能，有一些程序，我们知道很多Ruby程序里边有一些不同的程序，可能会有一些不同的参数，比如说这个程序可能有两个参数，可能有一个参数，或者是这个程序可能没有参数，我们可能通过在Ruby里边原来做的是，它可能在动态里需要判断这些参数个数。我们会把这些，如果在调用的时候，直接就去把这些参数个数给区分开，我就可以省掉每次去找那个或者判断不同的分支的那个过程。所以说的话，我最近在做的一个优化就是这样一个事情，就是可以让程序的性能得到一些提升。

   

24. 现在你们这个项目正在进行的工作主要包括哪些方面？如果说一个人有兴趣参与的话，它能在哪些方面做出贡献？

当然现在最大的工作可能就是在于Built in的开发，这个可能是，你如果想加入到XRuby或者这个项目里边，可能最容易入手的点，你可能通过很简单的数据，包括我们随着项目发布了一个XRuby Hacking Guild，里边有一个对这个怎么去做这件事，有一个自己的一个解释。你可去遵循那个XRuby Hacking Guild所写的东西，去尝试向那个XRuby里添加一些代码，这可能是最简单的一个入门的途径。此外呢，可能还有一些很有趣的工作在进行之中，包括现在做的一个Antlr 3的一个Parser。可能大家有一些人会认为，既然你们已经是编译器了，肯定是有自己的Parser，我们为什么去开发一个Antlr 3呢？一方面是因为一个性能的原因，就是英文，因为经过重新的整理以后，可能要比它的第二版快的多，另外一方面，Antlr 3的未来的一个目标，是支持Ruby的一个语法后端，就是通过这个解释器，可以声成一个Ruby的Parser，那这个意味着什么呢？如果就是我们将来可以开发出，用Ruby开发的一个Ruby的Parser，可能很多人到这儿还意识不到Ruby的Parser有什么好处，可能是它的真正的价值，我觉得就是在，可能和大家一起现在可能越来越重视的一个DSL，可能会直接相关，DSL似乎Domain Specific Language的一个缩写，很多人希望这个程序越来越简单，和业务靠拢，向自然语言靠的越近越好，那有了这个DSL呢，程序设计语言就可以让它更接近于人类的自然语言。我们也知道，Ruby有很强的一个DSL能力，就是它的Metaprogramming能力，如果我们再有一个，这个Ruby的英文的话，那换句话说，你不仅仅是可以用Ruby本身的那些能力，就Ruby自带的这个Metaprogramming的能力，你还可以用Ruby本身的这个Ruby的Parser去做一些语法上的定制，这样的话，会让你的这个DSL能力变的更为强大。这就是它的这个东西有趣，它的有价值的一个所在。另外一个还有一些，就包括是很有趣的一些工作正在进行中，包括我们在做的一些探索，包括我们对这个Runtime的一些优化，包括对整个结构的一些优化，这些工作都是随开发不断进行之中的。

   

25. 在最后我想请你用简单的一句话，送给所有关心XRuby或者对它感兴趣的这些观众？

怎么说呢，探索语言的实现是一件非常有趣的事，如果你有兴趣可以和我们一起来体会这些乐趣。