Ola Bini氏がOnigurumaのポートであるJoniがJRubyトランクに統合されたことを報告した(source)。
これは、JRubyとRegular Expression(Regex)間にあった永遠に終わらないように見えたお話の最後の部分に過ぎないかもしれない。初期のJRubyバージョンは RubyのRegeexesを実装するのにJava内蔵のRegex(Javas 1.4以降に含まれている)を使用していた。これはサードパーティのライブラリ、またはポートを要しないので一番シンプルなソリューションである一方、ま たそれはJRubyをそれに適応させないという問題ももたらした。JRubyはRuby1.8.x（かもしくは将来のバージョン）と互換性を保つことを目標としており、同じRegexeをサポートするのに必要なのである。Javaの実装は非互換となったが、それは部分的に、いくつかの表現を失敗させる要因となったアルゴリズムディテールのせいでもある。Ola氏はそのステップを解説した(source)。
これらの課題はまた、たくさんのRuby実装の代案にも共通している。(ほとんどの場合)Rubyによって書かれたRuby実装であるRubiniusは、Onigurumaを含むというシンプルなソリューションを使用している。JVMかもしくは.NETのようなVMに基づいたRuby実装は、ネイティブライ ブラリを含んでいることがデプロイメントを更に困難にするという問題を抱えている。それだけではなく、Marcin氏がOla氏のブログ上のコメントで説明 しているように他にも統合に関する課題があるのだ(source)。
なんという素晴らしい日だ！Joni(Oniguruma RegExpエンジンのMarchinの素晴らしいJavaポート）がJRubyトランクに統合されたのだ。現在それは大変上手くいっているように見えるよ。JRubyチームのメンバーであるMarcin Mielczynski氏はOniguruma(サイト・英語) RegExのポートをJavaコードに移行する仕事を行った。OnigurumaはRuby 1.9.×.に含まれているRegExpエンジンである。
これは、JRubyとRegular Expression(Regex)間にあった永遠に終わらないように見えたお話の最後の部分に過ぎないかもしれない。初期のJRubyバージョンは RubyのRegeexesを実装するのにJava内蔵のRegex(Javas 1.4以降に含まれている)を使用していた。これはサードパーティのライブラリ、またはポートを要しないので一番シンプルなソリューションである一方、ま たそれはJRubyをそれに適応させないという問題ももたらした。JRubyはRuby1.8.x（かもしくは将来のバージョン）と互換性を保つことを目標としており、同じRegexeをサポートするのに必要なのである。Javaの実装は非互換となったが、それは部分的に、いくつかの表現を失敗させる要因となったアルゴリズムディテールのせいでもある。Ola氏はそのステップを解説した(source)。
それを修復するために私達はJRegexを代わりに統合しました。それが1.0が一緒にリリースされたエンジンで、またそれは現在未だ使用されているエンジンなのです。その動作はなかなか良好で、またJavaエンジンにしては速いのです。でも十分には早くはありません。特に正確なストリングと欠点を素早く検索するサポートが無く、そのエンジンは私達がbyte[]-stringsをchar[]かもしくはStringに変換 することを要します。正確にはそれは最適ではありません。もう一つの問題は特にマルチバイトサポートにおけるMRIとの互換性であります。これらの問題は全てJoniで解決されるように見える。もしくは解決されるだろう。Regexパフォーマンスは過去において重大な問題であったが(例： JRuby on RailsにおけるOracle Mixの構築からのレッスンを参照(英文記事)してほしい）、Joniはその助けにもなりそうだ。Charles Nutter氏は新しいコードを伴うREXMLパフォーマンスを調査した(source)。
一連の基本的な最適化に目を通した後、私達が心配していたほとんどの重要な表現はJRegexと同じくらい、もしくはそれよりも良く機能していたので、Ola氏は過去二日間においてその会話を調べた。Marcin氏今後もはいろいろな最適化に取り組むのだが、Ola氏と私は両方とも新しいコードで遊んでいた。そしてその外観は素晴らしいものです。そのリンクされている記事は、Joniコードで大幅な加速を見せた統合前と統合後のコードを比較したベンチマーク結果に続いている。
これらの課題はまた、たくさんのRuby実装の代案にも共通している。(ほとんどの場合)Rubyによって書かれたRuby実装であるRubiniusは、Onigurumaを含むというシンプルなソリューションを使用している。JVMかもしくは.NETのようなVMに基づいたRuby実装は、ネイティブライ ブラリを含んでいることがデプロイメントを更に困難にするという問題を抱えている。それだけではなく、Marcin氏がOla氏のブログ上のコメントで説明 しているように他にも統合に関する課題があるのだ(source)。
私達はOnigurumaを含むことを既に考慮していました。それにはいくつかの理由があります。スレッディング: Onigurumaはコードレンジタブレットをイニシャライズする時か、もしくは共有ASTノード(Character Class発すテーブルのような)を管理する際にグローバルロックを使用します。Onigurumaバイトコードインタプリタも、またスレッドロックを使用しています(それは停止することもできますが、Java landで無償で手に入れることができ、外国のスレッドをjava oneと混合することはハッキングになるでしょう。)。例外: segfaultから回復するのは困難になるでしょう。OnigurumaのエラーをRubyの例外に変換したとしても、またそれは醜いハッキン グになってしまうでしょう。原文はこちらです：http://www.infoq.com/news/2007/11/oniguruma-joni-jruby
JNI: それはデータ分離を要すので、全てのストリング・バイトがコピーされる必要があるのです。
付加的なバイナリ分配: それを一つのメインフレームにコンパイルするのを頑張ってください:D