我认为您几乎钉牢了它。

JMRI还是另一个Ruby执行引擎，就像MRI，YARV，IronRuby，Rubinius，MacRuby，MagLev，SmallRuby，Ruby.NET，XRuby，RubyGoLightly，tinyrb，HotRuby，BlueRuby，Red
Sun以及其他所有引擎一样。

主要区别在于：

• 可移植性：例如，仅在x86 32位Linux上正式支持YARV。在OSX或Windows或64位Linux上不支持。Rubinius仅适用于Unix，不适用于Windows。JRuby OTOH 随处可见 ：台式机，服务器，电话，App Engine（随便命名）。它可以在Oracle JDK，OpenJDK，IBM J9，Apple SoyLatte，RedHat IcedTea和Oracle JRockit JVM（以及我可能遗忘的其他两个JVM）上运行，也可以在Dalvik VM上运行。它可以在Windows，Linux，OSX，Solaris，多个BSD，其他专有和开放式Unices，OpenVMS以及多个大型机OS，Android和Google App Engine上运行。实际上，在Windows上，与“ Ruby”（意味着MRI或YARV）本身相比，JRuby通过了更多的RubySpec测试！

• 可扩展性：在JRuby上运行的Ruby程序可以使用任何任意Java库。通过JRuby-FFI，他们还可以使用任何任意C库。借助JRuby 1.6中新的C扩展支持，他们甚至可以使用MRI和YARV C扩展的很大一部分，例如Mongrel。（请注意，“ Java”或“ C”库实际上并不意味着用这些语言编写，而仅意味着使用Java或C API。它们可以用Scala或Clojure或C ++或Haskell编写。）

• 工具：每当有人为YARV或MRI编写新工具（例如memprof）时，事实证明JRuby在5年前就已经有一个工具可以做同样的事情，但效果更好。Java生态系统拥有一些用于“运行时行为理解”的最佳工具（这是我刚刚编造的一个术语，它的含义不只是简单的概要分析，而是意味着可以深入理解您的程序在运行时的确切功能的工具，它的性能特征是什么，瓶颈在哪里，内存在哪里，以及最重要的 原因 是 为什么 所有这些都在发生）和市场上可用的可视化，至少在某种程度上，几乎所有这些都可以与JRuby一起使用。

• 部署：假设您的目标系统已经安装了JVM，那么部署JRuby应用程序（我不仅在谈论Rails，我还指的是台式机，移动设备，其他类型的服务器）实际上只是在复制一个JAR（或WAR）然后双击。

• 性能：JRuby具有更高的启动开销。作为回报，您可以获得更高的吞吐量。实际上，这意味着与运行集成测试一样，将Rails应用程序部署到JRuby是一个好主意，但是对于开发人员单元测试和脚本，MRI，YARV或Rubinius是更好的选择。请注意，许多Rails开发人员只是在MRI上进行开发和单元测试，在JRuby上进行集成测试并进行部署。无需为所有内容选择一个执行引擎。

• 并发性：JRuby同时运行Ruby线程。这意味着两件事：如果锁定正确，则程序将运行得更快；如果锁定不正确，则程序将中断。（不幸的是，MRI，YARV和Rubinius都不同时运行线程，因此仍然有一些坏掉的多线程Ruby代码不知道它坏了，因为显然并发错误只有在存在实际并发时才会出现。）

• 平台（这在某种程度上与可移植性有关）：那里有一些令人惊叹的Java平台，例如具有768 GiBytes RAM和864 CPU内核的Azul JCA，专门设计用于内存安全，指针安全，垃圾回收，面向对象语言。安卓 Google App Engine。所有这些都运行JRuby。