The Artima Developer Community
Sponsored Link

Musings on Language and Design
Creating an Interactive JRuby Console for the Eclipse Environment
by Jeremy Meyer
April 4, 2008
Excited by the possibilities afforded by JRuby and the ability to plug it into various different Java environments, I decided to try implementing a JRuby interactive console in Eclipse.


Plugging in JRuby

Like so many others my imagination has been captured by Ruby. Perhaps it is because of the steep rise in its awareness the software development community has undergone since Rails, perhaps it is a combination of its quirky constructs, enthusiastic (and often surreal) proponents, and the fact that DSLs are gaining respect and momentum. At the same time, the JVM is becoming an obvious platform choice and Java itself is starting to look a little tired and lost as a language.

Perhaps Java is reaching its sell-by date, after all, there do seem to be natural universal laws about these things; and they apply to a great many domains. Fashion, empires and programming languages are three that I can think of which adhere to these rules. They rise, dominate and fall. Sometimes they come back, (like flared trousers and interpreters) but even if they die, they always leave their legacy, like the Roman Empire, or Cobol.

Anyway, it is obvious that however long it stays in vogue, one such mark that will be left by Java is the JVM as a platform, and fascinated as I am by Ruby, I think that JRuby is (together with Rails) what will really keep it on the map. I find myself more and more regularly explaining to colleagues and clients (partly to prevent them rolling their eyes as one does when faced with a religious fanatic, or a pushy salesperson) that I only really love Ruby and crowbar it into every discussion I can, because compiled languages like Java exist. JRuby makes using Ruby sensible (and cool).

Why is this cool? Because like so many consultants, it is my job it is to help people come up with general, repeatable solutions to their problems, so I am always on the lookout for some sort of lazy reuse idea. Since all clients want those three very simple and clearly mutually exclusive features that constantly haunt us, i.e. good, fast and cheap, I find myself drawn to the model of leveraging powerful application libraries with glue code or something minimal, scriptable and clever. JRuby fits that bill quite nicely.

No Silver Bullet

I wouldn’t propose anything as a silver bullet, but I have seen so many projects fail for the same reasons, that I am tempted by anything that can cut out some of the badness.

This means doing all sorts of things, ranging from trying to improve communication of requirements down to proposing better techniques of project management (so agile methodologies are always a popular choice). But anything that helps to cut out as many middle-men as possible, and allows the people with more domain knowledge to get closer to the engineering of the solutions has to be a good thing.

Or does it? Isn’t this falling into the old trap of trying getting non-programmers to write programs? Haven’t previous attempts at this failed? Languages like BPEL and Visual Basic and even (looking back a bit further) Cobol have all, in their own way, in their own domains tried to make programming easy. These have all ended up producing horrible languages. In the case of the latter two they have also produced code bases huge and prevalent by virtue of their easy proliferation, not their suitability for solving the problem. Not popular with OO purists and lovers of aesthetically pleasing languages!

Well now we have more languages like JRuby(and Jython and Groovy etc.) which allow us pleasing constructs, great power and efficient syntax together with access to Java libraries and access to any platform which has a JVM implementation. More importantly, perhaps, is that this translates into access to any Java middleware. Excellent! This means that the powerful application stuff can be written by the software engineers and the business logic can be written (at least initially) by the domain experts, using a domain specific language (or domain specific flavour, if language isn't subtle enough). This should mean that we can give an expert in the domain of feet enough power to shoot themselves in the foot with a homing missile, and they wouldn't have to be a rocket scientist.

What is doubly pleasing of course, is the fact that Ruby by its nature is dynamic (as are some of the other languages which have JVM implementations), and building a domain specific language to solve a problem can be implemented quite elegantly. So helping prevent our domain experts from getting in too much trouble is a bit easier. We can expose the important bits to them and shield the complexity from them. Very importantly though, they will always have the full power of the language at their finger tips should they need it.

Triply pleasing perhaps, is the fact that you can do all of this in an interactive shell (jirb in JRuby) if you want to, which is a great and agile way to wire up existing domain libraries, or produce "glue code". You can embark on a learning adventure with a framework, or library and produce a solution that can form the basis of something permanent. For example, you can experiment with the creation of swing applications using JRuby from the interactive shell. This is so easy that even a sock puppet could do it (and did, see here!).

Scripting in an Eclipse Environment

I got to thinking that one of the environments it would be great to play with was the Eclipse environment. It is a mature, fairly solid platform, with a sound plugin model and some very powerful development tools available in it. What would be great, I thought, would be if you could script in it, or create macros, even. Creating an interactive shell would give you access to any plugins you liked. Certainly it seemed it would be a worthwhile effort plugging in an interactive shell to see what would happen. As a self-confessed non-expert-but-fascinated wannabe Ruby-ist, I thought I could kill two birds with one (precious) stone, i.e. learn more about the language and learn more about the Eclipse platform at the same time.

How did I do this? Some of the highlights follow below. If you really can’t bear the thought of looking through code, or want to see everything in its entirety, then download this zip which has the Eclipse plugin and the full source included:

The obvious place to start looking at how to do this was jirb, the interactive Ruby shell written for JRuby. Of course, I thought, this would be a Java console that read in a line of text and passed it to the Ruby interpreter for evaluation, so it couldn’t be too hard to re-implement this in an Eclipse app.

Turns out I was slightly wrong. The jirb command, it seems, is just a batch file that runs JRuby and points it to irb. So irb, the interactive Ruby shell, is just a Ruby program and jirb , the interactive JRuby shell is just irb running in JRuby.

The Ruby Code

After some head scratching, I realised that this was very cunning and would actually help make my life easier. I did some investigation into the irb code, and with help from a good (albeit old) article by Leonard Richardson about unit testing the Ruby Cookbook source code, I discovered that redirecting irb input and output is fairly straightforward. Turns out that all you need to do is extend the Ruby Irb class and get it to use our own input and output streams. The Irb class implements the strategy pattern to read from its input stream using an InputMethod. Creating an Input Method is as simple as providing a Ruby class which has a gets operation and a prompt= setter method. The prompt= setter method is necessary, because irb will throw exceptions without it, (although I admit I am stumped as to why it is there, it doesn’t seem to do anything other than pass in an empty string.)

I needed to customise my prompt, and get the line of text typed, so:

class EclipseConsoleInputMethod
  # echo the prompt and get a line of input.
  def gets
	$stdout.print 'eIrb:> '

  def prompt=(x)

And now, I could minimally extend the Ruby Irb class to give me a custom Irb class, which has the right context and some useful configurations:

class EclipseConsoleIrb < IRB::Irb

  def initialize(ec_inputmethod)
    IRB.conf[:VERBOSE] = false
    super(nil, ec_inputmethod)

  def run
    IRB.conf[:MAIN_CONTEXT] = self.context

Not too hard at all! Now what I needed to do was get an Eclipse console to provide said input and output streams and pass the typed Ruby code into the former and echo the results into the latter.

The Java Code

Eclipse’s IO Console does that job very well, it displays in the normal Eclipse Console area, provides and input stream for you, and can have multiple output streams directed to it, perfect. (You can even set colours for the different streams!)

I created a simple Eclipse Plugin application using the basic Eclipse "new project" wizard. All I had to do was create a subclass of an IOConsole that had an instance of the RubyInterpreter class in it ..

Highlights below:

import org.jruby.Ruby;

public class RubyConsole  extends IOConsole implements Runnable {

   public void run() {
      RubyInstanceConfig conf = new RubyInstanceConfig() {
         public InputStream getInput() {return in;}
         public PrintStream getOutput() {return out;}
         public PrintStream getError() {return err;}
      try {
         Ruby rubyRuntime = Ruby.newInstance(conf);
         String jRubyHome = System.getProperty("jruby.home");
         String jRubyVersion = System.getProperty("jruby.version");
         rubyRuntime.evalScriptlet("require 'jruby';");
         rubyRuntime.evalScriptlet("require 'eclipse_console_irb';");
      } catch (Exception e) {

I got the input output and error streams from the superclass IOConsole, and used them to create an inner config class of type RubyInstanceConfig. I then used that to make the Ruby Interpreter. You will notice that once I create the new interpreter I call the evalScriptlet method with some Ruby script code. First I add the paths to the Ruby load path by inserting into the special Ruby array $: . I then issue two require statements. One to start JRuby and one to load up my Eclipse console Ruby script, which contains the Ruby code already shown above.

The Console can be added to the GUI by a very simple piece of code. I chose to add it by creating an action that creates a new Console, so I have a new menu entitled Ruby Console

Highlights below:

static RubyConsole ruby = new RubyConsole();
   getConsoleManager().addConsoles(new IConsole[]{ ruby });
And that is it. There really wasn’t much more to it than that, so when I say highlights I actually mean almost everything. Most of what I have left out is the Eclipse plugin library code. All the Ruby code I needed is shown above.

After I build the plugin from my project, and deploy it, I get the rather pleasing result of a Ruby console in my Eclipse workbench with a eIrb>: prompt at the console, and the interpreter’s results shown as I type in commands. It even has nice colours. Shown here:

The Result

What can you do with this though? Well anything you like (within reason) but provided your plugin has added upstream plugins to its dependency list, you can load any Java classes you like from that plugin and work with them. For example, I have added the “org.eclipse.core.resources” to my RubyConsole plugin’s dependency list, and so I can access the Eclipse Workspace by typing:

eIrb:> include_class 'org.eclipse.core.resources.ResourcesPlugin'

irb responds with:
=> ["org.eclipse.core.resources.ResourcesPlugin"]

Indicating that I have loaded up the class..
eIrb:> workspace = ResourcesPlugin.get_workspace

=> #<Java::OrgEclipseCoreInternalResources::Workspace:0x25abb1 @java_object=org.eclipse.core.internal.resources.Workspace@12605d>
So I now have the workspace object stored in workspace. The great thing about this environment of course, is that should I feel I can’t be bothered to look in the Javadocs for the methods available on the Eclipse Workspace class, I can make use of Ruby’s reflection by just typing:
eIrb:> workspace.methods

Which returns a huge array of all the methods (too big to list here). I can then experiment with the sensible looking ones, and soon discover that:
eIrb:> projects = workspace.get_root.get_projects
eIrb:> projects.each { |p|
eIrb:> 	puts p.get_name
eIrb:> }

..will list all of the names of the projects in my Eclipse workspace, while:
eIrb:> projects[0].build(0,nil)

..will force the first project in the workspace to build.
eIrb:> projects[0].close(0,nil)

..will close the project, while:
eIrb:> workspace.get_root.get_project('project1').open nil
.. would open a project in my workspace called ‘project1’. Of course this is not good coding style at all, and if you didn’t have a project with this name, you would get a Java exception reported at the Ruby prompt, but you get the idea. All in all, this is a really agile way to develop and a great way to test and experiment with libraries and middleware. Of course, once you have a piece of Ruby code that does something useful, you can save it in a .rb file and use the Ruby’s require statement at the prompt to load it up. You would then be able to continue typing interactively.
eIrb:> require 'useful.rb'
I hope you have fun playing around with this. Enjoy!


The plugin with sourcecode. All version info, etc. in the readme.txt:

Puppets Do JRuby:

Talk Back!

Have an opinion? Readers have already posted 10 comments about this weblog entry. Why not add yours?

RSS Feed

If you'd like to be notified whenever Jeremy Meyer adds a new entry to his weblog, subscribe to his RSS feed.

About the Blogger

Jeremy has been designing and developing software for over 20 years, as well as teaching its mastery. He is fascinated by all aspects of architecture, design and development, the philosophical, the psychological and the aesthetic. He currently heads up the training division at hybris Software, a fast growing and very exciting eCommerce company.

This weblog entry is Copyright © 2008 Jeremy Meyer. All rights reserved.

Sponsored Links


Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use