JRuby 9K 产品就绪

作为JRuby的开发负责人之一，Charles Nutter在Baruco 会议上发表演讲的时候宣布将于2014年（第二季度或者晚些时候）发布版本9000（9K）。新版本的目标是实现和Ruby MRI 2.0（也可能是 2.1 ）同样的功能集合。Charles还深入剖析了基于Java虚拟机 (JVM)实现Ruby的动机，并且还构建了在产品中使用JRuby 9K的案例。

JRuby 9K将仅能在Java 7上运行，同时开发团队（由Red Hat提供部分支持）希望将它的功能路线图与Ruby MRI的路线图对齐。这个不寻常的版本名称产生的原因是，开发团队意识到下一个JRuby的自然版本将会是1.8或者2.0，因此它们决定使用9000以避免与Ruby MRI的版本冲突。

据Charles所言，对齐功能并且在垃圾收集和性能等领域利用JVM的革新将有助于JRuby 9K在产品系统中成为强有力的竞争者。Charles的基准数据显示，运行在Java 7上的JRuby在响应时间方面略优于Ruby MRI 1.8，但是当内存使用上升到200MB的时候，它的垃圾收集时间远远优于Ruby MRI 2.0。下面的图表显示了Charles的另一个基准数据，在多个Ruby版本上运行一个红黑树算法实现的结果：

JRuby和MRI之间存在区别的另一个热门话题是：前者使用多核支持先进的并发性。Charles推荐使用JRuby测试真实的多线程执行，但是他也警告说Ruby生态系统依然需要更成熟的工具去支持它们。虽然已有的类库（例如thread_safe、Hamster、atomic或者jo）已经能够极大的帮助开发者避免线程池和协调（coordination）、对核心结构的并行读/写以及常见的非原子更新等不安全的操作：

@count += 1
@cache ||= MyCache.new

Charles提到，基于JVM构建的其他好处是它的可移植性和可用性（哪怕是在严密控制开发环境的组织中），还有Java、Scala或者Clojure这些语言的类库生态系统，开发者可以在JRuby中直接调用这些类库。

Vicent Martí和Chris Kelly等其他的Baruco讲师则认为JRuby可以作为MRI和 Rubinius的一种替代方案，并鼓励参会者参与到他们的开发中。

查看英文原文：JRuby 9K Production Ready