JRuby 近况：1.6 RC1、JSR 292 及 Java 7 中的 NIO2、1.9.2 支持

JRuby 1.6 RC1 发布了，带来了一大串改进： Charles Nutter 给出了 JRuby 1.6 的一个概述，Tom Enebo演示了改进后的Windows 支持，Yoko Harada罗列JRuby API 的变化。

InfoQ 就 JRuby 的现状与未来采访了 JRuby 的Charles Nutter.

InfoQ：​JRuby 1.6 中有什么大的变化？​

JRuby 1.6 RC​有超过 2000 次提交，解决了超过 260 个问题。这让 JRuby 1.6 成为迄今为止最大的发布。​ JRuby 1.6 RC 中的主要特性有：Ruby 1.9 兼容性——JRuby 继续跟进 Ruby 的最新版本，即 1.9.2，JRuby 1.6​承诺改善大多数 1.9 应用程序的兼容性，包括支持新的编码 API。改善 Ruby 代码的性能——JRuby 1.6 吸纳了很多增量的性能改进内容，包括 Ruby 1.9 中更快的标准库，还为日后的开发打下基础。

改善 Windows 支持——JRuby 1.6 发布了新一轮的 Windows 支持内容，包括内置对 WIN32OLE 的支持，还有其他一些兼容性补丁​，它们让 Ruby 应用程序能无缝运行于 Windows 之上，就像在其他平台上一样。​

Ruby 1.9.2 的兼容性已经完成的差不多了。还有一些特性会安排在后续版本中：Encoding::Converter、非 ASCII 标识符以及“ripper”和“fiddle”库。​我们希望用户能在 1.9 模式中测试 JRuby，在 1.6.0 最终版前发现那些剩余的问题。

InfoQ：​纤程（Fiber）怎么样了？

JRuby 1.6 RC 中​已经有纤程了，我们在今后的版本中会继续改善性能。​

InfoQ：我想最近的 MLVM 已经有了协程（Coroutine）支持（ Lukas Stadler 的工作？）​；你有没有尝试过呢？​

我们已经尝试过了 MLVM，计划在后续版本支持它。​​

InfoQ：​Ruby 社区以及其他一些来自 Node.js 社区的人最近一直在谈论关于异步和非阻塞 I/O 的好处。你是怎么看待阻塞式 I/O 和非阻塞式 I/O 的？​

和其他东西一样，混合多种方法通常才是最好的。​​异步 I/O 允许你​将 I/O 通道放在一个工作队列里，当 I/O 通道等待时释放线程和资源。 对单线程运行时（例如 MRI 或 V8）而言，这很重要，因为只有一个线程可以工作。对那些像 JRuby 这样的多线程实现，异步​I/O 同样很有用，​但它也可以有多个并发工作线程来处理阻塞和非阻塞调用。​混用阻塞和非阻塞 I/O 提供了最大的灵活性，那些不支持异步的系统调用或库​也不会对此有什么妨碍。​

InfoQ：JRuby 好像同时提供两种方式​，因为它和 MRI 不同，JRuby 既有并行线程，又有​NIO。有没有什么非阻塞 I/O（或带有 Java 7 中的 NIO 2 的异步 I/O）​可以发挥的场景？​

在实现一个必须处理数以千计连接的服务器或客户端时，唯一的选择就是弄一个较小的工作线程池来处理大量异步 I/O 通道​。大多数用户都不会碰到这样的场景，但在你需要异步通道时，它是无可替代的。JRuby 的 I/O 子系统​直接构建于 NIO 之上，​这就有可能在线程之间复用可选 I/O 通道​。任何一个对高并发、高负载 I/O 感兴趣的 Ruby 用户都应该来看看 JRuby。​

InfoQ：对于 Ruby 2.0 最近的工作​你有什么看法，例如 Ruby Refinements ？你有没有尝试一下，或者试着在 JRuby 中实现它们（我相信你实现了一个关于选择器命名空间的初期概念）？​

Refinements 是一个很有意思的特性，我们希望规范再“细化”​一点后就支持它。如果可以安全地为 monkey-patch 分配命名空间，这就可以解决 Ruby 世界里的一个常见问题。我们在 Refinements 的讨论中贡献了评论和原型实现，而且在规范制定阶段会继续做一些模拟的范例实现。​

InfoQ：看起来 Java 7 可能会在 2011 年的某个时间成为现实；​你有没有计划在未来的某个 JRuby 版本（1.7、2.0……）​中使用 Java 7 的特性？如果有的话，会先做哪个特性（除了 invokedynamic）？

我们计划为 Java 7 特性增加端到端的支持。​具体来说，我们会大量利用 invokedynamic 和方法处理，让 JVM 能更方便地优化 Ruby 代码。对于 NIO2 中的文件系统级特性，我们也感到很兴奋，例如其中对符号链接的支持​、文件系统事件以及其他一些以前只能通过我们的本地 POSIX 扩展才能拥有的底层功能。​在进行文件系统操作时，NIO2 可能意味着 JRuby​能更接近本地 Ruby 实现。它也让 JRuby 成为了在跨平台衔接文件系统事件方面最可靠的 Ruby 实现。我们同时计划继续支持 Java 5 和 Java 6​。

InfoQ：JRuby 1.6 中有哪些性能改进​，其中哪一个是你想放在下一个版本中的？​

最大的性能方面的工作涉及到减少 Ruby 调用的开销。​在 JRuby 1.5 和更早的版本​中，所有的 Ruby 调用都会​在调用时占据一个 thread-local 数据结构。那个数据用于生成回溯​（backtrace​）、处理“super”​调用、决定当前的“self”​和包含类​等等。JRuby 1.6 中，​在生成回溯时不再需要这个数据结构了，这意味着很多 Ruby​方法现在的人为调用开销接近于 0​。这让一些大派发量的性能测试结果提升了好几倍​。​ 我们还开始了对未来的优化目标的实验工作​。上面提到的“回溯”​方面的工作还让一个名为“dynopt”​的特性成为可能，它可以在编译时使用 JRuby 解释器的信息​将动态调用转为直接的静态 Java 调用。JRuby 1.6 并不支持此特性，但你可以通过 -Xcompile.dynopt=true 开启它。在小型性能测试上，能产生巨大的性能差异。另一个实验工作与我们在优化的编译器有关。我们在构建​一个新的编译器和​中间表述，这样在我们生成 JVM 字节码前更容易做一些优化​。这允许我们用 JVM 可能还没​发现到的方式来预优化 Ruby 代码​。在未来的 JRuby 版本中，我们会继续在这两个特性上下功夫的​。​

查看英文原文： The State of JRuby: 1.6 RC1, JSR 292 and NIO2 in Java 7, 1.9.2 Support​