作为 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
暂无签名
中国开发者画像洞察研究报告 2024
分析开发者的行为模式、工作价值、职业发展等内容，帮助整个行业生态更深入地理解开发者，为他们提供更精准...
评论