Visual Studio的Ruby in Steel提供JRuby支持

作者: Werner Schuster/贾晓楠 编译 出处:InfoQ中文站　2008-03-19 09:41　   砖    好    评论  条 　进入论坛

阅读提示：Ruby in Steel是一个Visual Studio下的Ruby IDE，它已经出现一段时间了。最近，Ruby in Steel for IronRuby已经发布了alpha版本。为了搞清楚JRuby支持都包含些什么，以及为什么增加这些，在这个新特性发布前夕，我们访问了Huw Collingbourne。

Ruby in Steel是一个Visual Studio下的Ruby IDE，它已经出现一段时间了，尽管还欠缺一些特性，比如快速Cylon Ruby调试器。最近，Ruby in Steel for IronRuby已经发布了alpha版本。

现在，一个新的特性马上就要公布了：JRuby调试器的支持，其中的重点是快速调试。（不要跟Ruby in Steel的JRuby支持弄混）。为了搞清楚JRuby支持都包含些什么，以及为什么增加这些，在这个新特性发布前夕，我们访问了Huw Collingbourne。

记者：Visual Studio是如何支持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开发。还有很多更好的工具可供选择。

记者：跨语言调试：你能在调试时混合Ruby代码和Java代码吗？我的意思是，当你挂起一个调用Java方法的Ruby方法时，堆栈观察器能同时显示JRuby和Java的堆栈调用路径吗？

Huw Collingbourne：不行，这个调试器仅支持Ruby。

记者：这是个内部开发吗（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的内部接口也很容易掌握和使用——即使基本上还没有文档。

记者：它有什么速度优势？还有没有更快的地方了？

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的地方在于它很好得使用本地线程。这对服务器应用程序来说很重要。

记者：在JRuby 1.1中：调试器可以用于解释的、JIT编译的，以及AheadOfTime编译的代码吗？

Huw Collingbourne：我们还没有发现JRuby 1.1的任何问题——它是标准的Java（除了JNI代码以外）。但我们在试图优化它时发现一个有趣的地方：通过C或C++优化所使用的技巧（也就是那些 令程序更快的方法）几乎不起作用。事实上，在某些情况下，这种优化在Java中适得其反。我们怀疑这可能是由Java的HotSpot优化器造成的。它好 象更喜欢你来做简单的事情，而让它来做优化。

记者：你有没有包含一些工具使得部署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有没有足够的需求）。

记者：JRuby的特性有没有包括编辑功能？有没有计划支持GUI构建？

Huw Collingbourne：我们最近专注于Ruby的开发，没有计划扩展到对Java的支持。正如我刚才所说，已经有很多 优秀的Java IDE了。我们相信我们努力开发的成果远比做一个最好的Ruby IDE更有用。说到GUI支持，我们主要关注于提供编辑和调试工具。JRuby可以利用所有现有的特性，包括智能感知和带有断点、步进、深入观察变量等功 能的快速调试器。

而最近，我们开始着手于对各种类型的可视化设计工具的支持。我们的一些客户已经使用了beta版的Rails可拖放设计环境（'Visual Rails Workbench'），我们打算在三月底发布它。这个环境会很好地用于JRuby，就像用于标准Ruby一样。有了它，你能够在屏幕上设计全页面的布 局，而不用去写ERb（嵌入的Ruby）模板代码了。我们还有一个可视化表单设计工具，内建在IronRuby IDE中。我们要不要专门做一个JRuby的可视化工具可能完全取决于人们对这个工具到底有多大的需求。

记者：你为什么敢冒JRuby IDE的市场风险？让VisualStudio开发者考虑使用JRuby有没有市场？

Huw Collingbourne：答案很简单，我们想要让用户在开发时有不止一种版本的Ruby可供选择。几 年前，只有一种Ruby解释器——即标准的Matz Ruby解释器。但我们对JRuby最近的发展印象深刻，并且我们感觉到JRuby非常重要，绝不能忽略。还有，我们一直想要让我们的用户不会感到他们被 “锁定”到一些特定的厂商的特定技术上。我们想给他们提供尽可能多的选择。最近我们认为JRuby就是MRI最好的替代者。另外，JRuby还在积极的开 发中，谁知道一两年后它的地位会怎样？我们不想一直等着。这就是我们现在就决定支持JRuby的原因。

原文链接：http://www.infoq.com/cn/news/2008/03/jruby-support-ruby-in-steel