当前位置: 首页 > 工具软件 > Visual Ruby > 使用案例 >

Visual Studio的Ruby in Steel提供JRuby支持

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

现在,一个新的特性马上就要公布了:JRuby调试器的支持,其中的重点是快速调试。(不要跟Ruby in SteelJRuby支持弄混)。为了搞清楚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优化器造成的。它好 象更喜欢你来做简单的事情,而让它来做优化。
\u0026#xD;\n

InfoQ: 你有没有包含一些工具使得部署JRuby on Rails应用程序更容易些?

\u0026#xD;\n
Huw Collingbourne:最近我们提供了一套通用的Rails集成开发工具——比如,各种保存和运行脚本的工具,可以让你摆脱命令行。但我们目前还没有开发专门针对JRuby on Rails应用程序部署的工具。
\u0026#xD;\n

InfoQ: 它是免费版吗(就像IronRuby,如果我没记错的话)?

\u0026#xD;\n
Huw Collingbourne:这一次,我们的目标是只为我们的商业产品Ruby In Steel开发器提供JRuby支持。你说得没错,我们最近发布了一个IronRuby IDE的免费alpha版本(IronRuby本身仍然处于pre-alpha状态),我们会在IronRuby的完成版发布后继续提供仅用于 IronRuby的免费IDE。目前我们没有计划发布仅用于JRuby的IDE(老实说,我们甚至不知道人们对此IDE有没有足够的需求)。
\u0026#xD;\n

InfoQ: JRuby的特性有没有包括编辑功能?有没有计划支持GUI构建?

\u0026#xD;\n
Huw Collingbourne:我们最近专注于Ruby的开发,没有计划扩展到对Java的支持。正如我刚才所说,已经有很多 优秀的Java IDE了。我们相信我们努力开发的成果远比做一个最好的Ruby IDE更有用。说到GUI支持,我们主要关注于提供编辑和调试工具。JRuby可以利用所有现有的特性,包括智能感知和带有断点、步进、深入观察变量等功 能的快速调试器。
而最近,我们开始着手于对各种类型的可视化设计工具的支持。我们的一些客户已经使用了beta版的Rails可拖放设计环境('Visual Rails Workbench'),我们打算在三月底发布它。这个环境会很好地用于JRuby,就像用于标准Ruby一样。有了它,你能够在屏幕上设计全页面的布 局,而不用去写ERb(嵌入的Ruby)模板代码了。我们还有一个可视化表单设计工具,内建在IronRuby IDE中。我们要不要专门做一个JRuby的可视化工具可能完全取决于人们对这个工具到底有多大的需求。
\u0026#xD;\n

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

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

更新:Ruby in Steel中的JRuby调试器支持还没有发布——一旦发布我们会尽快提供链接地址。

\u0026#xD;\n

2008年3月7日更新: JRuby调试器宣布支持Ruby in Steel

\u0026#xD;\n

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

 类似资料: