Ruby in Steel 是一个 Visual Studio 下的 Ruby IDE，它已经出现一段时间了，尽管还欠缺一些特性，比如快速Cylon Ruby 调试器。最近， Ruby in Steel for IronRuby 已经发布了 alpha 版本。现在，一个新的特性马上就要公布了：JRuby 调试器的支持，其中的重点是快速调试。（不要跟 Ruby in Steel 的 JRuby支持弄混）。为了搞清楚JRuby 支持都包含些什么，以及为什么增加这些，在这个新特性发布前夕，我们访问了 Huw Collingbourne。
InfoQ: VisualStudio 是如何支持 Java 的？你有没有增加一些支持，使得采用 JRuby 来开发跨语言的应用程序变得可能 / 容易（“跨语言”的意思是：使用 JRuby 代码来调用已有的 Java 库）？
Huw Collingbourne：VS 2005 的 Java 支持还可以，但不够好。本质上，Java 支持是通过微软的“Java dialect”来做到的，即 VS 2005 中的 J#。它具有语法着色和一些智能感知（IntelliSense）功能。但是在 VS 2008 中，微软移出了 J#，这意味你无法再获得 Java 支持了。即使你在 VS 2008 中打开 Java 代码，也只能使用普通文本编辑功能。要在 VS 2008 中生成一个用于 Java 的着色包组件并不难。我们能做到，但这不是我们想做的。支持一个调试器才更难。总而言之，我不推荐用 Visual Studio 来做正经的 Java 开发。还有很多更好的工具可供选择。
InfoQ: 跨语言调试：你能在调试时混合 Ruby 代码和 Java 代码吗？我的意思是，当你挂起一个调用 Java 方法的 Ruby 方法时，堆栈观察器能同时显示 JRuby 和 Java 的堆栈调用路径吗？
Huw Collingbourne：不行，这个调试器仅支持 Ruby。
InfoQ: 这是个内部开发吗（SapphireSteel 内部）？还是你基于已有的技术，比如 jruby-debug（基于跟踪的 JRuby 调试器，但为了加快运行，用 Java 写的，一个 ruby-debug）？
Huw Collingbourne：我们从头开始，混合使用几种语言写了这个编译器。它并不基于 jruby- debug。它的一部分是用 Java 写的，但通过 JNI 接口调用 C 来提高速度。慢的代码是用 Ruby 写的（比如处理用户输入），快的代码是用 Java 写 的，而更快的代码是用 C 和 X86 汇编语言写的。它使用 JRuby 的标准事件钩子方法来连接到 JRuby。JRuby 的一个有趣的地方是它的调试 / 跟踪系统 的兼容性很强。它与标准的 Matz Ruby（MRI）版本并不完全相同，但很相似，所以很容易上手。实际上，它比 MRI 的跟踪系统更易用，因为你无须为获得必需的接口而在解释器中做些乏味的事。另外，JRuby 的内部接口也很容易掌握和使用——即使基本上还没有文档。
InfoQ: 它有什么速度优势？还有没有更快的地方了？ > Huw Collingbourne：目前为止，我们还没有用 benchmark 与 jruby-debug 进行对比测试。它在我们的机器上运行不起来，无论如何，它还是 beta 版（我们这样认为）。所以，用 benchmark 对比可能不公平。尽管如此，既然 jruby-debug 是把 C 语言写的 ruby-debug 直接移植到 Java 上去的，我们预期我们的实现也会和 jruby-debug 具有类似的速度优势（介于 50% 到 100%），因为它已经超越了 ruby-debug——并且由于使用 JNI 组件的原因，我们的实现可能还要更好一些。不过，我们能够用 benchmark 与我们自己的基于 C 的 MRI 调试器 (‘Cylon’) 进行比较。我们的 Java 版好像比 MRI Cylon 版慢 2 到 3 倍。这几乎完全是由于调用 JRuby 的跟踪函数和调用 MRI 中 C 的跟踪函数的速度有差别所致。比起 MRI，JRuby 本身通常会具有一样的速度——可能还会更快一点，但不要惊讶。我们认为 JRuby 胜出 MRI 的地方在于它很好得使用本地线程。这对服务器应用程序来说很重要。
InfoQ: 在 JRuby 1.1 中：调试器可以用于解释的、JIT 编译的，以及 AheadOfTime 编译的代码吗？ > Huw Collingbourne：我们还没有发现 JRuby 1.1 的任何问题——它是标准的 Java（除了 JNI 代码以外）。但我们在试图优化它时发现一个有趣的地方：通过 C 或 C++ 优化所使用的技巧（也就是那些 令程序更快的方法）几乎不起作用。事实上，在某些情况下，这种优化在 Java 中适得其反。我们怀疑这可能是由 Java 的 HotSpot 优化器造成的。它好 象更喜欢你来做简单的事情，而让它来做优化。
InfoQ: 你有没有包含一些工具使得部署 JRuby on Rails 应用程序更容易些？
Huw Collingbourne：最近我们提供了一套通用的 Rails 集成开发工具——比如，各种保存和运行脚本的工具，可以让你摆脱命令行。但我们目前还没有开发专门针对 JRuby on Rails 应用程序部署的工具。
InfoQ: 它是免费版吗（就像 IronRuby，如果我没记错的话）？
Huw Collingbourne：这一次，我们的目标是只为我们的商业产品 Ruby In Steel 开发器提供 JRuby 支持。你说得没错，我们最近发布了一个 IronRuby IDE 的免费 alpha 版本（IronRuby 本身仍然处于 pre-alpha 状态），我们会在 IronRuby 的完成版发布后继续提供仅用于 IronRuby 的免费 IDE。目前我们没有计划发布仅用于 JRuby 的 IDE（老实说，我们甚至不知道人们对此 IDE 有没有足够的需求）。
InfoQ: JRuby 的特性有没有包括编辑功能？有没有计划支持 GUI 构建？
Huw Collingbourne：我们最近专注于 Ruby 的开发，没有计划扩展到对 Java 的支持。正如我刚才所说，已经有很多 优秀的 Java IDE 了。我们相信我们努力开发的成果远比做一个最好的 Ruby IDE 更有用。说到 GUI 支持，我们主要关注于提供编辑和调试工具。JRuby 可以利用所有现有的特性，包括智能感知和带有断点、步进、深入观察变量等功 能的快速调试器。
而最近，我们开始着手于对各种类型的可视化设计工具的支持。我们的一些客户已经使用了 beta 版的 Rails 可拖放设计环境（‘Visual Rails Workbench’），我们打算在三月底发布它。这个环境会很好地用于 JRuby，就像用于标准 Ruby 一样。有了它，你能够在屏幕上设计全页面的布 局，而不用去写 ERb（嵌入的 Ruby）模板代码了。我们还有一个可视化表单设计工具，内建在 IronRuby IDE 中。我们要不要专门做一个 JRuby 的可视化工具可能完全取决于人们对这个工具到底有多大的需求。
InfoQ: 你为什么敢冒 JRuby IDE 的市场风险？让 VisualStudio 开发者考虑使用 JRuby 有没有市场？
Huw Collingbourne：答案很简单，我们想要让用户在开发时有不止一种版本的 Ruby 可供选择。几 年前，只有一种 Ruby 解释器——即标准的 Matz Ruby 解释器。但我们对 JRuby 最近的发展印象深刻，并且我们感觉到 JRuby 非常重要，绝不能忽略。还有，我们一直想要让我们的用户不会感到他们被 “锁定”到一些特定的厂商的特定技术上。我们想给他们提供尽可能多的选择。最近我们认为 JRuby 就是 MRI 最好的替代者。另外，JRuby 还在积极的开 发中，谁知道一两年后它的地位会怎样？我们不想一直等着。这就是我们现在就决定支持 JRuby 的原因。
更新：Ruby in Steel 中的 JRuby 调试器支持还没有发布——一旦发布我们会尽快提供链接地址。
2008 年 3 月 7 日更新: JRuby 调试器宣布支持 Ruby in Steel
评论