News

The content has been bookmarked!

There was an error bookmarking this content! Please retry.

JRuby support in Ruby in Steel for Visual Studio

Posted by Werner Schuster on Mar 06, 2008

Sections: Development
Topics: Debugging ,; .NET ,; Java ,; JRuby ,; Ruby
Tags: IDEs ,; IronRuby ,; Visual Studio ,; JRuby

Ruby in Steel, a Ruby IDE for Visual Studio, has been around for some time and had to offer features such as the fast Cylon Ruby debugger. Recently Ruby in Steel for IronRuby has been released as an alpha version.

Now, a new feature will very soon be announced: JRuby debugger support, particularly focused on fast debugging. (Not to be confused with : JRuby support for Ruby in Steel ). To find out what this JRuby support includes and why it was added, we talked to Huw Collingbourne ahead of the release of this new feature.

InfoQ: What's the Java support in VisualStudio like? Do you add any support to make developing cross-language applications with JRuby possible/easy ("cross-language" meaning: using JRuby code to script existing Java libraries).

Huw Collingbourne VS 2005 Java support is OK but not great. Essentially, Java support is provided via Microsoft's 'Java dialect', J#, which is included in VS 2005. This gives you syntax coloring and some IntelliSense. But in VS 2008, Microsoft has removed J# which means that you don't get any Java support at all. When you load Java code into VS 2008 you really don't have much more than a plain text editor to work in. It wouldn't be that difficult to build a coloring package for Java in VS 2008. This is not something we have committed ourselves to doing but, in principle, we could. Support for a debugger would be more difficult. All in all, I wouldn't recommend Visual Studio for serious Java development. There are far better tools available.

InfoQ: Cross language debugging: Can you mix Ruby code and Java code while debugging? I mean, when you suspend a Ruby method that calls into a Java-source method, does the stack view show the stacktraces of both JRuby and Java?

Huw Collingbourne No. The debugger is Ruby only.

InfoQ: Is this an in-house development (at SapphireSteel) or are you basing it on existing technologies, such as jruby-debug (trace based JRuby debugger, but written in Java to make it faster, a la ruby-debug)?

Huw Collingbourne We've written our debugger from the ground up in a mix of languages. It isn't based on jruby-debug. Some of the JRuby debugger is written in Java but it calls into C components via the JNI interface for speed. The slow bits (for example, handling user input) are written in Ruby, the fast bits are written in Java and the really fast bits are written in C and X86 assembly language. It uses JRuby's standard event hook methods to link into JRuby. Incidentally, one of the interesting things about JRuby is how compatible the debug/trace system is. It isn't exactly the same as the standard Matz Ruby (MRI) version, but it's so similar that it's easy figure out what's going on. In fact, it's easier to use than the MRI trace system because you don't have to do unpleasant things inside the interpreter to get the required interfaces. Also, JRuby's internal interfaces are easy to follow and use - even if the documentation is almost non-existent.

InfoQ: What kind of speed advantage are we talking about? Are there any areas that are much faster?

Huw Collingbourne So far, we haven't been able to benchmark against jruby-debug. It wouldn't build on our machines and, in any case, it's still beta (we think), so a benchmark comparison might be unfair. However, since the jruby-debug is a straight port of the original C ruby-debug into Java, we expect that our implementation will have a similar speed advantage (between 50% and 100%) over jruby-debug as it has over ruby-debug - and possibly a good bit more because of the JNI components. We have been able to benchmark against our own MRI C-based debugger ('Cylon'), however. Our Java version seems to be about 2 to 3 times slower than the MRI Cylon. This is due almost entirely to the speed differences between the JRuby trace function and MRI's C trace function invocation. JRuby itself seems generally to run at about the same speed - possibly a bit faster - than MRI, but nothing startling. We think that where JRuby may win over MRI is in its good implementation of native threads. These are important for server applications.

InfoQ: In JRuby 1.1: does the debugger work with interpreted, JITed and AheadOfTime-compiled code?

Huw Collingbourne We haven't discovered any problems with JRuby 1.1 - it's standard Java (apart from the JNI code). But one of the interesting things we found when trying to optimise it was that optimisation tricks that work in C or C++ (i.e. things that make the code go faster) have little effect. In fact, in some cases, they even a negative effect in Java. We suspect that this may be due to the Java HotSpot optimizer. It seems to like you to keep things simple and let it do the work.

InfoQ: Do you include any tools to make deploying JRuby on Rails apps easier?

Huw Collingbourne Currently we supply a set of general purpose integrated development tools for Rails - for example, various utilities to save and run scripts without being forced to navigate to a command prompt. But we do not currently have any tools specifically for deploying JRuby On Rails apps.

InfoQ: Is this a free version (like the one, if I remember correctly, for IronRuby)?

Huw Collingbourne At this time, it is our aim to provide JRuby support only within our commercial product, Ruby In Steel Developer. You are right, we have recently released a free alpha version of an IDE for IronRuby (which itself is still in pre-alpha) and we will continue to provide a free IronRuby-only IDE after the finished version of IronRuby is released. We don't have any plans at present for a JRuby-only IDE (to be honest, we don't even know if there would be sufficient demand for such an IDE).

InfoQ: Is there any editing support for JRuby specific features? Any plans for GUI building support?

Huw Collingbourne Currently we are focussed exclusively on Ruby development and we don't have any plans to expand into Java support. As I said above, there are already plenty of good Java IDEs anyway. We believe our development effort is much better spent on making sure we have the best Ruby IDE possible. As for GUI support. Up to now we have concentrated principally on providing editing and debugging tools. JRuby can take advantage of all the existing features including analytical IntelliSense and a fast debugger with breakpoints, step-into/over, drill-down watch variables and so on.
Recently, however, we have started moving towards support for visual design tools of various sorts. Some of our customers are already using the beta version of a drag and drop design environment for Rails (the 'Visual Rails Workbench') which we expect to release at the end of March. That environment will work just as well with JRuby as with standard Ruby. So you will be able to design full-page layouts on screen as an alternative to writing ERb (embedded Ruby) templates in code. We also have a visual form designer built into our IDE for IronRuby. This will let IronRuby programmers create standalone desktop applications in a similar way to C# or Visual Basic. Whether or not we decide to work on support for dedicated visual tools for JRuby may all depend on how much demand there is for such tools.

InfoQ: What are your reasons for venturing into the JRuby IDEs market of? Is there a market of VisualStudio developers thinking of using JRuby?

Huw Collingbourne The simple answer is that we want to give our users the choice of developing for more than just one particular version of Ruby. A couple of years ago, there was only one Ruby interpreter that mattered - the standard Matz Ruby Interpreter. But we have been impressed with the developments of JRuby recently and we feel that JRuby is far too important for us to ignore.
Besides, we have always wanted to make sure that our users don't feel that they are 'locked into' some specific technology from a specific vendor. We want to provide them with the greatest range of choices possible. Currently we think that JRuby offers the best alternative to MRI. Besides, JRuby is still being very actively developed and who knows how important it may be a year or two from now? We don't want to wait that long to find out. Which is why we have decided to support JRuby now.

Update: The JRuby debugger in Ruby in Steel support has not yet been release - we'll provide the link as soon as it is.
Update 7th March 2008: The JRuby Debugger support for Ruby in Steel has been officially announced.