Sun公司收编JRuby

2006-09-11

9月初，Sun公司雇佣了JRuby开源项目的两个核心开发人员Charles Nutter和Thomas Enebo，专职从事JRuby开源项目的开发工作。从Charles Nutter和Thomas Enebo的私人博客的字里行间，我们可以感受到他们对Sun公司对于JRuby项目认可，以及对JRuby项目提供了大力支持而无比振奋。

这是Charles的blog
http://headius.blogspot.com/2006/09/jruby-steps-into-sun.html

单纯从web项目的开发效率上衡量，Java已经无法和ruby on rails相提并论，但有趣的是Java并非完全站在ruby on rails的竞争对立面。由于ruby的第三方库远远无法和Java相提并论，其运行效率也无法和成熟的JVM相比，而我们知道，JVM从理论上来说，也并非可以仅仅支持Java一种语言。因而将ruby移植到JVM上面来，结合ruby的开发效率优势和Java丰富类库支持，强大Java运行平台优势就是顺理成章的事情了，JRuby正是实现这一目标的框架。而Sun对于JRuby提供的强力支持，更加表达了Java与ruby携手的决心。

当前JRuby还仅仅只是使用Java来解析执行ruby程序，目前已经可以支持ruby1.8.4，而且可以把ruby on rails的简单应用跑起来了。但是由于不是bytecode级别的解析，因而执行效率很低。JRuby team未来则期望能够直接在Java平台上面把ruby程序编译为bytec ode执行，以达到本地Java代码的效率。不管怎样，JRuby项目的前景都是值得我们期待的。

10:47
浏览 (14071)
评论 (18)
分类: Java
进入论坛
相关推荐

dreamhead 2006-10-26

fyol 写道

但实际上，我只觉得用JVM来解释Ruby是最有用处的，可以解决ruby的效率问题，ruby 和 java混用好像用处不大吧，除非是，有些组件只有java里面有，看着眼馋

你说了一个大家都希望的事实，在JVM上直接运行Ruby。但是这个也是说起来容易，做起来难。

可以直接想到的方案有两种：
直接把代码转成bytecode。如果你了解Ruby的实现，实际上，Ruby的类结构在运行时可能会发生变化，比如include一个module，或是为某个对象定义singleton方法，这个过程都可能产生一个新的类，在Ruby中称之为singleton class，然后把这个类插入到现有类继承体系中去。当然，这个类在Ruby的层次上不可见。简而言之，就是A继承自B，现在有个C，让A继承自C，C继承自B。在Java的bytecode一级动态修改类之间继承关系如何来实现，不知道哪位对此有高见。这只是转换过程中遇到的一个问题，对此问题深入研究下去，会有更多有趣的问题。

用Java语言写一个Ruby的runtime，也就是自己维护Ruby底层的对象之间的关系。事实上，JRuby也是这么做的。但稍微可以改进一点的是，直接用Java语言去写方法，直接用JVM去执行，而不用去像JRuby一样，再去用解释执行的方式转换成内部结构，再用自己写的虚拟机去执行。同JRuby的方式相比，这样的做法效率上会稍有一些提高，主要体现在对方法的处理上。

如果哪位想到什么更好的方式，可以一起来讨论一下！

fyol 2006-10-26

上周JRuby 0.9.1 新版本发布了。

JRuby是一个Ruby脚本语言的纯Java实现。JRuby可以嵌入任到Java应用程序并可以在脚本中使Java类。

此次发布的新版本中主要新特性是，增加了对Rails的支持。也就是说，理论上你可以在JVM上运行Rails了。

其他的提升包括：
- Overall performance is 50-60% faster than JRuby 0.9.0
- Improved Rails support
- New syntax for including Java classes into Ruby
- New interpreter design
- Refactoring of method dispatch, code evaluation, and block dispatch code
- Parser performance enhancement
- Rewriting of Enumerable and StringScanner in Java
- New experimental syntax for implementing interfaces
- 86 Jira issues resolved since 0.9.0

"理论上你可以在JVM上运行Rails了" 这句话很好玩

dreamhead 2006-10-25

JRuby的慢，主要问题不在于前端解析上（当然对比C还是慢一些），而是后端代码运行上。去看一下JRuby的代码，就会发现JRuby实际上是用Java写了一个Ruby的虚拟机。Ruby的虚拟机本来就不快，现在有个YARV的项目，就是为了改善Ruby虚拟机的性能。可想而知，用一种跑在虚拟机上的语言（Java）去写一个不快的虚拟机（Ruby），性能高才是件怪事。

geszJava 2006-10-05

关心groovy的性能...为什么非要搞成ruby那要所有的东西都是对象,没必要,根本没必要.应该允许简单类型的存在.

cryolite 2006-09-19

sun直接支持groovy不更好吗？

cookoo 2006-09-16

JRuby还是解释方式的，有个编译器正在内部开发中。另外一个消息是有个我们的同胞正在搞一个Ruby到Java字节码的编译器：

http://xruby.com/default.aspx

代码在http://code.google.com/p/xruby/

njmzhang 2006-09-16

JRuby 0.9应该还不是编译成字节码，速度慢得惊人。
一些特性好像也不支持，比如callcc

YuLimin 2006-09-16

能详细讲讲执行效率很低的具体数据不？如直接Ruby运行与在JRuby上面运行的对比？

Allen 2006-09-15

引用

Summary
In this presentation from InfoQ Day at Java One, Thomas Enebo and Charles Nutter show off the current state of the JRuby project, which has come a long way under their stewardship. The presentation shows compelling demonstrations of how the Ruby language and key Ruby applications can function well on the Java Virtual Machine.

Bio
Charles Nutter of the JRuby development team has been working to redesign JRuby's core interpreter and improve compatibility with Ruby 1.8. Lately he has been focusing on getting key Ruby applications to work. JRuby Project Manager and lead developer, Thomas Enebo is interested in web application development and the Ruby programming language.

http://www.infoq.com/presentations/JRuby

charon 2006-09-14

cookoo 写道

huangyi，ironpython编译成什么样的IL代码？因为jython虽然编译成字节码但实际还是内嵌一个python解释器，所以虽然有VM提供JIT但速度和cpython还是在仲伯之间。C#编译出的IL代码速度一般是cpython的10－20倍左右，ironpython有cpython的5倍就非常不得了。

我记得原文说是很多情况下ironpython性能优于cpython，这个很多就很难界定了。就和前段时间有帖子说python写的程序比C写的快一样
如果是计算密集型，还是shootout的结果比较客观一点，毕竟大家都是python语法，就不存在是不是贴切实现的问题了
http://shootout.alioth.debian.org/gp4sandbox/benchmark.php?test=all&lang=python&lang2=iron
至于典型情况下如何，谁也说不清楚。除非用这两种实现对所有的标准库和知名的第三方库和软件进行benchmark，这个就不太可能了

cookoo 2006-09-14

charon 2006-09-12

发现这不是Sun的第一次，前一个是TCL，不过现在已经离开了
http://blog.csdn.net/ganxingming/archive/2006/09/11/1210067.aspx

huangyiiiiii 2006-09-12

IronPyton 是将 python 程序编译成 .net 的 IL 代码，执行速度已经比 CPython 要快了。
我想不管是 IconPython , 还是 JRuby，它们都不是给python或ruby程序员用的，而是给 .net/java 程序员用的。

cookoo 2006-09-12

charon 写道

IronPython也实现了绝大部分的python标准库。
关键的问题是社区资源的共享，或者说双向兼容性。首先是原生脚本移植到其它VM平台版本的问题，理想情况是任何的标准脚本，只要是 python/ruby的，那么不论跑在哪个VM版本上，就应该能够顺利跑起来。但是因为一些依赖关系，某些特殊的语法缺失，以及大量第三方lib特别是那些用C/C++编写的lib的移植问题，使得这几乎成为一个奢望。最近jruby为了让rails顺利跑起来作了很多工作，但是现在还不能算是大功告成。如果移植的代价小，或者有便利的工具可用(就像现在开始编写的经典python程序向python3000的移植工具)，这个还是可能执行的任务，但是对社区而言，浪费了太多的重复劳动
另一个方向是从VM版本的脚本程序向标准版本的移植。实际上，如果使用IronPython或者JRuby，肯定是想在.net或者jvm上作一些平台相关的动作,不论是从界面或者性能方面来考虑。这样，这种移植实际上是不可能的。
将来很可能是有一个主流的标准版本(不论这个版本是不是目前的C/C++版)，和一堆支流，这些支流或者各有特色，但从发展上来看，总是很难跟上主版本的步伐(这次IronPython是个例外，号称实现了2.5的特性)，而且其延续存在性很大程度上决定于少数几个关键开发者的兴趣(比如jython自从创始人去搞ironpython之后，几乎陷于停顿)

你说的有道理，不过移植VM这件事有利有弊，还是让‘市场需求’来决定吧。本来python和ruby对移植性都是比较宽松的，何况不同的项目对移植性和功能实现有不同的诉求。

charon 2006-09-11

robbin 写道

IronPython和JRuby可能还是不太一样的。dotnet平台实际上提供了自己统一的dotnet fraemwork类库，所谓不同的编程语言支持，更像是一种语法糖衣而已。但是JRuby其实实现了大部分ruby自己的库，用JRuby并非仅仅用一个ruby语法而已，关键是ruby本身的方便的库和rails框架，至于Java库的支持，只是辅助了。

Sun对JRuby的支持表明了一种态度，这种态度是承认ruby在企业快速开发方面的优势，而对ruby提供更好的支持。而Microsoft支持的IronPython更像是用python语法写C#程序那种感觉，换汤不换药。

robbin 2006-09-11

charon 写道

我现在对这类动态语言的非本质实现抱很大的怀疑态度。
最近除了这个新闻以外，IronPyton(python的.net版本)1.0也发布了。但看了一下，感觉虽然不是特别差，也是差得可以。也许这是给那些熟悉.net同时又想找一个动态语言的人一个选择？
两个语法相同但是标准库有差异(jruby可能语法上也略有差异)，支持库有重大差异的语言，还能算是一个语言吗？
当年不论出于什么原因，Sun对于MS污染java的行为举起了大棒，现在这几个开源社区的动态语言，却纷纷搞出这么些方言来，不好说阿。

charon 2006-09-11