Visual Studio的Ruby in Steel提供JRuby支持

作者 Werner Schuster译者 贾晓楠 发布于 2008年3月14日 下午8时59分

社区

Ruby,

.NET,

Java

主题

调试,

JRuby

标签

IDE,

IronRuby,

Visual Studio,

JRuby

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

查看英文原文：JRuby support in Ruby in Steel for Visual Studio

• 更早的 >