Barucoカンファレンスで行われた講演の中で，JRuby開発リーダのひとりであるCharles Nutter氏は，バージョン9000(9K)を2014年中(第２四半期以降)にリリースすると発表した。Ruby MRI 2.0相当の機能セットが目標だが，可能ならば2.1も対象にするという。さらに氏は，Java仮想マシン(JVM)用のRubyインプリメンテーションの背景となったモチベーションについての見解を披露すると同時に，JRubyの実用性に関しても言及している。
JRuby 9KはJava 7でのみ動作する。開発チーム (その一部はRed Hatがサポートしている) としては，Ruby MRIとロードマップを一致させて行きたいと考えている。不自然なバージョン名は，本来ならば1.8あるいは2.0になるはずだったのだが，Ruby MRIのバージョンとの混乱を回避したいと開発チームが考えたことから，9000という名称を用いることになったものだ。
機能的に同等であることに加え，ガベージコレクションやパフォーマンスなどの面でJVM環境のメリットを活かせることで，JRuby 9Kは，プロダクションシステムへの採用において強力な選択肢となるだろう，と氏は述べている。氏の実施したベンチマークではJava 7上で動作するJRubyが，レスポンス時間の面でRuby MRI 1.8よりもわずかに優れたパフォーマンスを示している。メモリ使用量が200MBに達したときのガベージコレクション時間においては，Ruby MRI 2.0を大幅に凌駕する。下のチャートは氏が実施した別のベンチマークからのもので，赤黒木(red/black tree)アルゴリズムをさまざまなRubyインプリメンテーション上で実行した結果を示している：
MRIと差別化するためのトレンディングトピックのもうひとつは，マルチコアを活用した高度な並行性である。氏はJRubyを使って真のマルチスレッド実行を試してみるように勧める一方で，マルチスレッドをサポートする完成度の高いツールがRubyのエコシステムに必要だ，とも警告している。とは言っても，スレッドプールや調停処理，コア構造体の並列読み込み／書き込み，あるいは次例の非アトミックな更新処理のように，安全でない操作を回避する方法としては，thread_safe, Hamster, atomic, あるいはjoなどのライブラリがすでに存在する：
@count += 1 @cache ||= MyCache.new
その他，JVM上に構築するメリットとして氏が言及したのは，可搬性と可用性 (厳密に管理された開発環境を持つ組織であっても) についてだった。さらにJavaやScala，Clojureといった言語のライブラリのエコシステムがJRubyからは直接的コール可能である，という点も忘れてはならない。
Vicent Martí氏やChris Kelly氏など，Brancoカンファレンスでの他の講演者たちも，MRIの代替としてJRubyやRubiniusを支持すると表明して，カンファレンス参加者の開発への寄付を呼びかけていた。