JRuby 1.3が現在利用可能になっており、多くのパフォーマンスの改善とバグフィックスがもたらされた。新しい改善は、Nailgunが含まれるようになったこと、より高速なタイムアウト、などである。(NailgunやJava1.4のサポートの終了など、1.3における変更に関するより詳細な情報はこちら).
JRuby 1.3は、Google AppEngineのJavaサポート上で動作する初めての安定版リリースでもある。
新しいバージョンのtimeoutには問題が残っているようである。その問題はJRubyのtrunk版では修正されている。今はJRubyをtrunkからビルドする手間が必要であるが、1.3.1リリースはこの修正を加えた形で利用可能になると思われる。
同時に、JRubyの速度の改善に関する作業が続いている。コンパイルされたJRubyを改善するプロジェクトの一つがruby2javaである。
Ruby2Javaコンパイラはクラスの「実行時」定義を調べて通常のJavaクラスを生成します。すべてのメタプログラムされたメソッドは、メソッドに対する実行時変形と同様に、Javaクラスに反映されます。
ruby2javaプロジェクトはKenaiにホストされている。Ruby2javaを実行するには最低でもJRuby 1.3が必要である。
ruby2javaは、現在すでにあるJVM上でJRubyの速度を改善することを目的としている。しかし、JDK/Java 7におけるいくつかの新しい変更によって、著しい効率の改善が見られるかもしれない。JSR-292は、この目的を達成するためのJVMに対する変更のうち、最初のいくつかを集めたものである。
変更の一つは新しいバイトコードinvokedynamicの導入であり、これによってメソッド呼び出しに関するカスタムルックアップメソッドを提供することが出来るようになる。すなわち、あるメッセージがレシーバに送られたときに、言語ランタイムを呼び出して、そのルックアップを利用して実際に実行するメソッドを返却する、というようなことが可能になる。これ自体は大きな改善をもたらすわけではないかもしれないが、JVMがこういったタイプのメソッド呼び出しに関するよりよい最適化をもたらし得ると考えられる。
このアプローチは何年もの間議論され続けてきたが、ゆっくりと現実のものになろうとしている。JavaOne'09においていくつか講演がJSR-292に関するものであった。新生VMに向かって (リンクはスライドのオンライン版)とJSR 292クックブック (リンクはスライドのオンライン版)である。これら2つの講演では、その変更に関して深く議論されているし、JVMに対して将来行われるであろう変更に関するアイデアも提供している。
Charles Nutter氏はまた、JRubyでinvokedynamicと新しいメソッドハンドルを利用することを進めていて、初期バージョンのコードがJRubyブランチで利用可能である。
新しいフィーチャーはJVMのリサーチ版かまたは初期のJDK 7ビルドでのみ利用可能である(invokedynamicは数週間前JDK 7ツリーに含まれるようになった)。