最年夜的改善是:
我们还做了不计其数的修补来兼容Ruby1.8.6。JRuby是今朝为止与Ruby兼容性最好的第三方完成了,并且很长工夫内城市一向是。
- 一个完全的编译器,用来把Ruby代码转换成Java字节码(bytecode)
- 重写了IO子体系,使它更好地婚配Ruby的功能
- 我们的新Regexp引擎撑持Ruby字符串,而且功能年夜幅提拔
- 整体功能比1.0一切的刊行版都要好很多倍
通用的Ruby代码几近都应当运转地快很多,出格是在它利用了大批正则表达式的情形下。一样平常来讲,假如一段Ruby代码在JRuby中运转得不如在Ruby1.8.6中快的话,我们就以为这两头呈现了成绩,因而我们就查找成绩呈报,来办理一切遗留的瓶颈成绩。
基础上,这个正则表达式引擎完整移植于Oniguruma——这是Ruby1.9将接纳的Regex引擎。我们的移植是由MarcinMielżyski完成的,仿佛具有更优的功能,并且还修改了原Oniguruma中仍存在的一些毛病。这个新的完成比其他一切的基于Java的regex引擎体现得都要好,而且还与Ruby1.8和Ruby1.9具有极好的兼容性。我们重写了年夜部分的Regexp和字符串办法,来无效地利用新引擎。
由于Ruby的字符串只是字节汇合,因而JRuby完成也利用Java字节数组。恰是因为这个缘故原由,现有的Java正则表达式引擎对我们来讲体现的都欠好;一切的regexp操纵都要把byte[]转回char[]。但JRuby成员之一MarcinMielzynski挖空心思地移植了Oniguruma——这一个Ruby1.9所利用的基于byte[]的编码有关的(encoding-agnostic)正则表达式引擎。多亏了他的“Joni”库,如今我们有了比之前更好的regexp撑持,而且基础上一切的regexp功能成绩都办理了。这是一项巨大的事情,一个伟大的奉献。
现在Ruby1.9还处于开辟版,尚没有对我们形成很年夜影响。我以为它会在两方面临我们有所匡助:第一,1.9的特征将更不乱,也就是说我们更简单把它们准确地加到JRuby中。第二,因为我们正盘算入手下手察看1.9的实在功能,我们就有了一个好的方针来对照。如今我们基础上在一切的尺度评测中都凌驾了1.8。
我们已入手下手把1.9的工具到场JRuby了,并且我们还会持续这么做下往。固然如今起首要包管准确性和修改毛病。比方Oniguruma的移植让我们为字符串等增添编码撑持变得加倍简单。
我们还没有会商到2.0。从我团体来讲,我以为2.0会是个完整兼容1.9和1.8的版本。为了JRuby1.2,我们会努力于Java集成和内部API。我们的Java集成特征如今事情的十分好,但个中仍有一些毛病和低效力的工具,以是我们盘算对谁人子体系做一次完全的反省。这毫无疑问是个次要的事情,并且劳绩也会很棒。
你差未几在一切的方面都能看到功能的提拔。可是在那些我们可以静态地指出基于仓库的当地变量充足平安,又没有利用eval,也没有甚么时兴工具中央,功能才进步得最多。在那些办法中,我们一般能够从编译器中取得伟大的功能提拔,并且假如它们是你程序中的热门的话,这也会年夜幅改善一样平常的运转时。
在JRuby1.1以后,我们最想看到的两个方面是对1.9的撑持和更好的Java集成。这些事情大概会作育JRuby1.2,大概年夜到间接进进JRuby2.0。固然了,我们也会经由过程精益求精功能来坚持抢先……可是到今朝为止,我们已对它十分中意了。
我们正思索在JRuby1.1公布一段工夫后入手下手努力于Ruby1.9的特征。但是我们也但愿在我们花了大批工夫在1.9的特征上时,它能坚持不乱。看起来1.9开展的很快,但我们可不想在来岁往追逐1.9特征的变更。
我想我们不管怎样都要展现一下JVM的dynlang的惊人潜力。即便这意味着要为OpenJDK制造一个新的,大概还不太兼容的工具,那也值得。没有来由会让这个事情不克不及准确地集成到Java中,但的确存在难以相信的VM守候被开辟。我想既然人们已意想到了他们进进了甚么,往年对OpenJDK来讲会是主要的一年。而你能够见证JRuby的事情会使用人们提出的一切OpenJDK实行。
欢迎光临 仓酷云 (http://ckuyun.com/) | Powered by Discuz! X3.2 |