郑晔谈Ruby on JVM和XRuby

受访人 熊节 发布于 2007年8月9日 下午8时38分

社区

Ruby,

Java

主题

Ruby on Rails,

JRuby

标签

XRuby,

JRuby,

开源软件

概要
在这个视频采访中，InfoQ中文站的社区编辑熊节和开源项目XRuby的核心开发成员郑晔谈到了在Java平台上支持Ruby的具体考虑、Ruby在JVM上的执行效率、编译和解释代码的区别以及XRuby项目的发起和目标等话题。另外采访还涉及到XRuby对Rails的支持、JRuby和XRuby项目的融合等。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

现在XRuby它的目标是什么？

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

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

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

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

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

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

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

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

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

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

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

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平台里边实现了，这是我觉得是，二者可能很大的一个差别的地方吧。

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

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

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

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

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

当然现在最大的工作可能就是在于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的一些优化，包括对整个结构的一些优化，这些工作都是随开发不断进行之中的。

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

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

 

1. 返回顶部

   太卡

   2007年8月12日 上午8时5分 发表人 qi xiang

   播放太不流畅了，几乎没法看！ infoQ英文如此，中文还是如此！

   回复

2. 返回顶部

   Re: 太卡

   2007年8月12日 下午9时34分 发表人 Jason Lai

   不知道楼上的朋友用的是什么样的上网线路呢？我在网通和电信观看这个视频的效果都是很好的。我们的视频是根据在512k ADSL的带宽情况下播放而优化的；另外，为我们提供视频流服务的提供商，在上海是有服务器集群的，因此可以尽可能的避免走国际带宽的传输瓶颈。 不过，会出现播放不流畅现象，我觉得跟时间段有关系，根据我在以前观看主站视频的经验，在早晨和下午效果一般比较好，晚上可能会稍差些。

   回复

3. 返回顶部

   Re: 太卡

   2007年8月13日 上午5时49分 发表人 Jack Wang

   我就是用512k的ADSL看得，非常流畅，而且也很清晰，当然，如果提供下载地话就更好了

   回复

4. 返回顶部

   老兄别来无恙

   2007年8月13日 下午7时33分 发表人 Shayne Yuan

   还是这么能侃，面善可掬。 只是这提供的访谈环境也太差了，简直就是在审讯。

   回复

5. 返回顶部

   r

   2007年8月15日 上午12时1分 发表人 ray Li

   呵呵 郑大大总是一副很开心的样子

   回复

6. 返回顶部

   Re: 太卡

   2007年8月16日 上午1时39分 发表人 sj zhang

   教育网也不行，老断

   回复

7. 返回顶部

   感谢郑晔！

   2007年8月16日 上午2时6分 发表人 Jin Xiangdong

   感谢ThoughtWorks、感谢郑晔给大家带来的这些 Ruby 知识！

   回复

8. 返回顶部

   一个拼写错误

   2007年8月27日 上午5时2分 发表人 BaoZhen Cao

   XRuby Hacking Guild 应该是Hacking Guide.

   回复

9. 返回顶部

   郑大人加油 ！！

   2007年9月4日 上午1时36分 发表人 Yu Su

   郑大人加油 ！！

   回复

10. 返回顶部

    我在移动，卡死。

    2007年9月5日 下午8时51分 发表人 静波 曲

    卡。

    回复

11. 返回顶部

    XRuby加油！

    2007年11月29日 上午12时53分 发表人 Jerome Chen

    在这里看到了郑晔对XRuby的一些介绍，感觉是非常的不错的。不过长路漫漫，还需努力啊。 ---------------------------------------------------- [Ruby中文社区] - www.ruby-lang.org.cn

    回复

• 更早的 >