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​