5: JRuby and JFreeChart

At last! Ruby and Java together! What a magic combination!

I've been a Java application developer for a decade now, and my Perl and other scripting activities have almost always been a completely separate activity. Although I tried JPython a few years ago, and it was fun and productive, it didn't stick. But now I've tried JRuby and got far more done preparing this snippet than expected, so I'm definitely impressed!

JRuby

The context for the first part of this article is that our development team works on Java desktop applications and have often considered having an embedded scripting environment for faster customization of the applications for specific needs, and custom system integration work. Our first try with JPython a few years back, while still hanging around in the code-base, is not used nearly as much as we had hoped. I have more hope for JRuby. Consider these quotes from doing a google of 'jruby':

• I used to think that the killer feature of JRuby was making it easier to sneak Ruby into companies via a Java back-door. …JRuby’s killer feature is its brilliant integration with Java code. (Curt Hibbs –O’Reilly)
  
• You will begin to hear reports of Rails running on the JVM in both development and production environments with very little disruption to existing code bases. This will be followed by blog post after blog post extolling the virtues of being able to drop down into Java for performance critical pieces of code and how nifty JFreeChart is. (Ryan Tomayko - Dec’06 Predictions for 2007)
  
• But in the past year, it's become apparent that we could actually exceed Ruby's performance for specific cases in the near term, and for general cases over time. So the target market for JRuby seems to be changing from "Ruby users that must use Java VMs, libraries, and servers" to "Ruby users that want a better-performing, more scalable implementation". (Charles Nutter – blog 16-4-07)
  

JFreeChart

The second item in this talks title is JFreeChart. This arose from a need to add charting capabilities to the user interface of our pure java application. While it took me over two hours of Internet searching and reading of descriptions and reviews to find JFreeChart, it took only a further one hour to add the necessary charts to our application. Considering that this hour included trying out some of their demo code, and reading some basic JFreeChart documentation, I was amazed at how quickly it was possible to code for this amazingly complete charting library.

And it is truly a comprehensive library, as evident from this screenshot from the JFreeChart homepage:



JRuby & JFreeChart

As I arrived at the office on the day I planned to give this talk, I met a colleague in the stairwell, and told him that I had the idea of writing a JRuby application in less than ten lines that loads an Alcatel Switch data file into a JFreeChart bar-graph giving a cool live animation. I wanted to see how simple it would be to write an entire application in Ruby, including dynamic user interface including charts and relevance to the telecoms data and problem domain our team works with. Well, it ended up taking 20 lines of code (26 if you include comments and blank lines), but that is still impressively short considering all it does:



OK. It is a bit longer than most ruby snippets I usually like to present, but it is very easy to read, with three sections clearly separated by comment lines. The first sets up the required application swing components, the second prepares the JFreeChart chart and dataset, and the third is the actual plain ruby code for reading the telecoms switch data file, parsing it and adding the relevant statistics to the chart, while conveniently modifying the chart title dynamically. As usual, the same application in pure java is at least three times as many lines.



It is hard to appreciate the coolness of seeing this chart dynamically update itself while the data is loaded from disk. The chart animates, with the title and the bars changing smoothly. Of course, dynamic animation has little engineering value to our customers, and we did not use that feature in our actual commercial application, but I definitely had jaws dropping in the room when I gave this talk :-)

My final impression:- Ruby is a lovely language, and Java is the industry standard platform with the widest 3rd party library support, and this combination is absolutely a killer combination. So although I started this talk with the idea of adding ruby scripting to java applications, I'm now thinking more of writing Ruby applications that simply use Java libraries.

And of course, I can't wait to try Rails on JRuby!

Links:

• JRuby - http://www.jruby.org
• JFreeChart - http://www.jfree.org
  

4: Ruby regular expressions

In the wireless engineering applications area I work, we often have to deal with new data types and formats, and for years I relied on Perl for fast and convenient scripting to deal with data conversion and data validation. I never became a master at all that Perl offered, but was very proficient in a number of key areas applicable to these kinds of problems, notably text file manipulation, data management and regular expressions. This knowledge was valuable also when using regular expressions in Java, initially with the OROMatcher library and later with the standard regex library in java 1.4, but Java was never as convenient and concise as Perl, which was always a small irritation.

Needless to say I was thrilled to discover that Ruby regular expressions were the best of both worlds, with the conciseness of Perl and the Object-Orientation of Java. My first example here is a comparison of a Perl script with the Ruby equivalent:



This Perl script opens a text file and iterates over all lines, splitting each line on the ';' character and using a regular expression to extract two important bits of data out of one of the fields. The results look something like the following:



OK, so this data might not mean anything to you if you don't work in mobile network engineering, but the principle stands. The Perl script is short and simple, and the single line regular expression very useful. The Perl syntax for this was $fields[1] =~ /ID \"(\w+)\", cellRef (\d+)/, which basically compares the second field to the regular expression, and stores the two parenthesized substrings in the convenience variables $1 and $2. Concise, simple and powerful. The Ruby example is almost exactly the same:





Amazingly this is even shorter than Perl, since we merged the two loops into one, with Ruby's lovely File.open.each convenience methods, and we have less punctuation, but otherwise the scripts look almost identical, and the regular expression line is nearly exactly the same, with only the first '$' removed. For Perl fans, this is wonderful. But what about the Object Orientation fans out there? Perls regular expressions are not apparently object orientated, and the use of global variables $1 and $2 in both the Perl and Ruby examples does not please everyone.

The good news is that this Ruby approach is actually a convenience wrapper on what is fundamentally a very object orientated regular expression library in Ruby. And of course you can write the code in a very OO way, remarkably similar to Java. Consider the following Java example:





As with the previous two scripts, the output is identical. However, the program code is much, much more verbose, to the extent that I had to shrink the font size to fit it on the page! Firstly we have the required Java class and static main method plumbing, and then the java.io plumbing to open and read the file. The String.split method introduced in Java2 helps, and looks somewhat like the Perl and Ruby version, but the regular expression code is sure ugly - lots of steps: creating Pattern, Matcher objects and so many methods: compile(), matches(), and group(). Whew!. So is there anything good about this approach? Well, it is object orientated, and no global variables are used, and if you work in eclipse you can ctrl-space on all objects to figure out what to do next, aiding programming very much. It is relatively easy to code, but somewhat less convenient to read later.

So how does Ruby do this? Let's re-write the previous Ruby script using a purely object orientated syntax:





Wow! Amazing! The Ruby version of the program is almost exactly like the Java version, constructing a Regexp object, calling match, and then extracting the groups with the [] method. But it certainly looks a lot less verbose than the Java version, and is definitely easier to read. It is not as concise as the Perl-like Ruby script before, but it has achieved a clean object-orientated approach with no use of globals, while only being a little more verbose. Nice!

For a clear comparison of the two Ruby versions, I place them here side by side with the line including the regular expression highlighted. The differences are not that great, even though if you did the same comparison between Perl and java you might have trouble seeing the connections. Ruby has found a great way to bridge the gap:

3: Ruby Threads

In this short snippet I introduced our Java programmers to Ruby threads by showing them a simple example that used the Ruby classes Thread and Monitor which are very similar to their java equivalents. Consider the following example:

The last line represents the final result printed out: 14141. But if you take a look back at the code you can see that there are two threads created, t1 and t2, each of which is counting 10000 times and incrementing the same counter 'c'. You might easily expect this to result in the counter reaching 20000, but it did not. This is a simple example of a very well known problem with multiple threads accessing shared resources, and the solution is equally well known.

The key is the line '@count += 1' where the internal counter is incremented. The reason this fails to count all the way to 20000, the number of times the 'tick' method was called, is because this operation is not atomic. As indicated in the pseudo-code to the right of that line above, there are actually three separate steps to this increment operation, and it is very likely that one thread might be part way through this when the other enters. So thread t1 gets the current value of @count, but before it can store the incremented value, thread t2 gets the current value (now old value). t1 stores the incremented value, but then t2 also increments and stores the old value, so the final result is only one increment, not two. If this happened every time, the total would be only 10000, and if it never happened the total would be 20000, so we can see from the result 14141 I got above that it happened more than half the time. Just how many times this happens in reality depends on many factors, so the final total is quite unreliable.

As I said before, the solution to this is well known, but before we get to that let me comment quickly on the differences between this code and the Java equivalent. In java we would also create a Thread class and run it. But in order to pass the block of code in, we would have to instantiate a Runnable instance, with a run method, which is a lot more 'plumbing' than in Ruby. Another difference is that Ruby starts the thread on construction, while in Java you still need to call the start() method. I always thought the Java way made complete sense, but have yet to write a Ruby thread where I missed being able to call start later. In the end, a single line for constructing a thread, passing it code to run in a Ruby block and having it run directly is very concise and convenient, and certainly much easier to read.

Now for the solution to the problem. In Java we would use a concept called a 'monitor' which is built into every java Object, with the result that all objects have methods like wait() and notify(), and Java has the language keyword 'synchronized' which can be applied to methods and blocks of code. In some ways this could be seen as a case where Java has more convenience than Ruby, which does not have the Monitor built into every single object. But Ruby's overall elegance still keeps it beautifully concise. In Ruby you need to extend the class 'Monitor', or include the mixin 'MonitorMixin' if you have already extended some other class. See the example below where I've indicated with arrows the changes required to use the Monitor.

The blue arrows include Monitor support, and the red arrow is the key change to the code to make the '@count += 1' line atomic to multi-threaded access. Very easy indeed. In this case Java would have been simpler. We would not need any of the blue changes, and the red change could be done exactly as in ruby by synchronizing a block, or even simpler by synchronizing a method. But still the overall application is much shorter in Ruby, and the block synchronization is by itself simpler than java due to Ruby's cool code blocks, which make the Monitor#synchronize method look remarkably similar to the java 'synchronized' keyword. In fact this is a nice example of how Ruby has avoided the need for many keywords, and even leads to the subject of extending the language through libraries, which is beyond the topic of this snippet :-)

2: Ruby metaprogramming

Last week I ended with a short example of blocks together with metaprogramming. Today we’ll start with that example:


Although we successfully modified the Range class by adding a new method to use instead of each, we could have modified each itself, and I will show that later. But first let’s define metaprogramming.

Metaprogramming

Here is an extract from the wikipedia definition of metaprogramming:

Metaprogramming is the writing of programs that write or manipulate other programs (or themselves) as their data or that do part of the work that is otherwise done at run time during compile time. In many cases, this allows programmers to get more done in the same amount of time as they would take to write all the code manually.
The language in which the metaprogram is written is called the metalanguage. The language of the programs that are manipulated is called the object-language. The ability of a programming language to be its own metalanguage is called reflexivity.
A simple example of a metaprogram is this bash script, which is an example of generative programming:

Classes and Objects

Back to our example, where we added the method myTest to the class Range. We could instead have added the method to only a single instance of Range:


Take a look at ‘Programming Ruby’ for more examples.

Mixins

Ruby does not support C++ style multiple inheritance for the same reasons Java does not. It is seen as too easy for the programmer to hang themselves. However Ruby supports a concept that lies somewhere between java’s interfaces and C++’s multiple inheritance. Here is an example from Bruce Tates ‘Beyond Java’:


We have created a module called ‘Greetable’ that provides an implemented method ‘greet’. If Greetable is ‘mixed-in’ to a class that has a defined attribute @name, then that class will have a working greet method. If the class does not have @name, it is created dynamically by greet, refers to nil, which in turn displays as an empty string in the greet method. As a Java programmer you can almost hear the ‘NullPointerException’ that would happen in Java could get anywhere close to this capability.
Let’s try a mixin that modifies a pre-exiting method. Ruby defines ‘inspect’ on every Object, and it returns a description of the Object. Let’s redefine it:


Wow. In the same bit of running code we called the normal inspect, redefined it and called it again. Dynamic languages rule!

Interceptors

Another example by Bruce Tate, available both online and in ‘Beyond Java’, demonstrates the possibly dangerous power you have when redefining methods, in this case to emulate the java concept of ‘method interception’:

Strangely enough this example did not work in the normal ruby interpreter, only in irb, the interactive interpreter, and I never did discover why.

Full circle

I promised I’d show how the original example can be changed to rather redefine the Range.each method. Well, here it is:


We use the Ruby method ‘alias_method’ to rename the each method to original_each, and then we redefine each to call original_each, but with some small changes. Obviously this example does not do much, but the possibilities are limitless.

This 'snippet' was a little longer than planned, and took nearly 30 minutes to present, including questions. So next week I'll present only a single example of Threads in Ruby, and keep it short :-)

1: Ruby blocks and iterators

The first time I saw Ruby code, the 'blocks' stood out like a sore thumb. They were everywhere. Sometimes it was obvious what the code did, sometimes not. I was intrigued. Of course, once I started programming Ruby, I learned to love blocks. They are a really cool and expressive way of doing things that can be quite a lot less convenient in Java. I am not going to explain all the details of what blocks are and how they work (see ‘Programming Ruby’ if you want to know that). I’m simply going to show you a few examples, to give you an idea.

Iteration

Consider the classic ‘for’-loop. In many C-like languages the syntax is the same as in Java:


In Ruby there are a few ways of doing what the above code does, but using blocks you can be very concise:


One important point about this is that the each method is actually called only once, not three times, but it in turn will call back into the block three times, each time passing the latest value of ‘i’.

Code injection

In java we can also pass code into a method to be called when necessary, but it requires defining specific interfaces. Here is an example based on some real code we have in a regression testing framework used to test one of our products every night:

Wow, that was verbose. We needed to define the interface ‘CustomTesting’, and each time the main test method ‘doTest’ is called we pass an implemetation of that interface so that it can be called in the middle of the test. This seems simply like a much more verbose way of doing what Ruby blocks do, and in this example that is true. But Ruby takes this one critical step further. The local scope available at the time the block is passed into the method is still available within the method. That is not true in Java, and is a very important difference.

Ruby method blocks

So, what does this look like in Ruby.


Much simpler than in java, that’s for sure. But this example does not show anything beyond the java example. Two things ruby supports that really interest me are:

• Local scope
• Metaprogramming

There will be examples of local scope in laters snippets, and I have decided to devote the entire next snippet, all 15 minutes of it, to metaparogramming.

Ruby blocks and metaprogramming

Although I have decided to devote the next snippet to metaprogramming, here is a quick taster:

This is very similar to the previous example, but I have actually modified the Range class to have a new method to call, and I do so instead of the ‘each’ method I used before. You can even change the ‘each’ method to do something different than before. Next week I’ll discuss this in more detail.

Mini tech-talks

Recently I've begun giving a weekly series of ultra-short tech talks to the other developers in our office. The original problem we had was that, while we were all interested in learning about, or hearing about, technologies outside our working domain, it was generally not possible to spent office working hours on projects not directly of benefit to the company. The solution has been to give 15 minute talks during normal coffee-breaks. One really positive aspect of this is that it forced me to focus on a single specific 'hot' topic, and thereby blocking my usual tendency to lecture on for hours. While the resulting tech-talks are not comprehensive, they were easily digestible. Anyway you can always go to the books referenced below if you want something comprehensive.

These ‘snippets’ follow my progression as I learned Ruby, JRuby and Rails from the books I read, internet articles, and trial-and-error with real scripting projects I did. Each week I thought of something that was of particular interest to me as a Java and sometimes Perl programmer, and presented it in a 2-4 slide ‘snippet’. Where possible I used examples directly relevant to the work we do, which is mostly Java programming of data models and numerical analysis in mobile phone networks (not mobile phones). Sometimes I used examples from the books I read along the way:

• Beyond Java, Bruce Tate, O’Reilly – which got me interested in Ruby and Rails


• Programming Ruby, 2nd Edition, Dave Thomas, Pragmatic Programmers – which taught me what I needed for me first few scripting projects


• Agile Development with Rails, 2nd Edition, Dave Thomas and David Heinemeier Hansson, Pragmatic Programmers – which got me finally into Rails, after more than a year of hearing the buzz

For a more specific Ruby-2-Java comparison, see the extract in ComputerWorld of the book ‘Rails for Java Developers.’ This is a nice soft intro to Ruby for Java developers. However, while my snippets are not as complete, I think they are more interesting and relevant to me, of course. And I hope they will be of interest to others too.