Tom Purl’s Web Site

Update (8/8/09): When I was originally comparing Jruby & Groovy, I was under the impression that Jruby was a beta-quality product, and its cryptic error messages seemed to prove this point.  After a bit more research, I learned that Jruby is a robust and high-quality Ruby implementation and that all dynamic languages can give you cryptic errors on occasion.  Many thanks to the knowledgeable Jruby and Groovy developers who set me straight.

Background

I’m a middleware systems administrator for a living, and I often find that I need to write a script that has to interact with proprietary Java libraries. In the past, this meant writing a small Java program that would use the proprietary libraries, and then wrapping that program in a small shell script. This process was OK, but it did have its warts. For example, Java is a fairly verbose language. Going through all of the syntactic hoops just to write a simple program can be tedious.

A little over a year ago, I then discovered Groovy and Jruby. Both languages were very elegant, and I could see how they could both boost my scripting productivity dramatically. I therefore compared both languages for my scripting tasks, and, in the end, I determined that Groovy was just a better language. Here’s part of my rationale:

• A More Stable Interpreter – Jruby would often give extremely cryptic errors when you made a mistake, while Groovy did a much better job of pointing out any problems.
• A Compiler – At the time, Groovy had a compiler (groovyc) that use could use to compile your scripts into bytecode. This tool made it much easier for me to deploy Groovy code in my environment. Jruby has since introduced a similar tool, but it didn’t exist during my initial evaluation.

Now I’m on a new project, and we need to write a bunch of administrative scripts in a hurry. We have the same requirements as my old project, but just before I could dive into my Groovy interpreter, I found out that a lot of the Java developers on my team were ga-ga for Ruby. I therefore decided that it would be nice to evaluate both languages again, one year later. If Jruby is nearly as stable as Groovy for my needs, then it might be a good idea to start writing my scripts with it.

Evaluation

Before I could start my evaluation, I thought it might be a good idea to re-acquaint myself with Ruby. I read “Everyday Scripting With Ruby” a little over six months ago and thought that it was an excellent tutorial on both Ruby and agile scripting. I therefore decided to try running some of the examples in that book with Jruby to bring myself back up-to-speed.

In “Everyday Scripting With Ruby”, the first chapter encourages you to enter invalid code into irb, which is the Ruby interactive interpreter. This exercise shows you how to read the error messages returned by irb. Here’s the line of code:

 100 -= 43

And here’s what the latest-and-greatest (1.1.5) version of jirb (Jruby’s version of irb) returns when you enter that:

 irb(main):001:0> 100 -= 43
 SyntaxError: (irb):2: , unexpected tOP_ASGN

         from E:/apps/jruby-1.1.5/lib/ruby/1.8/irb/workspace.rb:81:in `irb_binding'
         from E:/apps/jruby-1.1.5/lib/ruby/1.8/irb/workspace.rb:53:in `eval'
         from E:/apps/jruby-1.1.5/lib/ruby/1.8/irb/workspace.rb:81:in `evaluate'
         from E:/apps/jruby-1.1.5/lib/ruby/1.8/irb/context.rb:219:in `evaluate'
         from E:/apps/jruby-1.1.5/lib/ruby/1.8/irb.rb:150:in `eval_input'
         from E:/apps/jruby-1.1.5/lib/ruby/1.8/irb.rb:259:in `signal_status'
         from E:/apps/jruby-1.1.5/lib/ruby/1.8/irb.rb:147:in `eval_input'
         from E:/apps/jruby-1.1.5/lib/ruby/1.8/irb/ruby-lex.rb:244:in `each_top_level_statement'
         from E:/apps/jruby-1.1.5/lib/ruby/1.8/irb/ruby-lex.rb:230:in `loop'
         from E:/apps/jruby-1.1.5/lib/ruby/1.8/irb/ruby-lex.rb:230:in `each_top_level_statement'
         from E:/apps/jruby-1.1.5/lib/ruby/1.8/irb/ruby-lex.rb:229:in `catch'
         from E:/apps/jruby-1.1.5/lib/ruby/1.8/irb/ruby-lex.rb:229:in `each_top_level_statement'
         from E:/apps/jruby-1.1.5/lib/ruby/1.8/irb.rb:146:in `eval_input'
         from E:/apps/jruby-1.1.5/lib/ruby/1.8/irb.rb:70:in `start'
         from E:/apps/jruby-1.1.5/lib/ruby/1.8/irb.rb:69:in `catch'
         from E:/apps/jruby-1.1.5/lib/ruby/1.8/irb.rb:69:in `start'
         from E:\apps\jruby-1.1.5\bin\jirb:19Maybe IRB bug!!

Yikes. I’ve been reading Java stack traces for seven years, but I really have no idea what this error message is telling me. If I honestly thought that line of code should work, or was tired and trying to meet a deadline, this stack trace would be anything but helpful to me.

Just to compare things a bit, I tried to same line of code in the 1.5.6 version of groovysh, which is the interactive interpreter for Groovy:

 groovy:000> 100 -= 43
 ERROR org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed, groovysh_evaluate: 2:
 [100] is a constant expression, but it should be a variable expression at line:
 2 column: 5. File: groovysh_evaluate @ line 2, column 5.
 1 error

Ok, still a little confusing, but much easier to follow. Basically, it’s telling me that “100″ should be a variable of some type instead of a literal. That makes sense.

I thought this might be an anomaly, and I wanted to give Jruby another shot, so I tried executing the next “broken” line of code from the book in both jirb and groovysh:

 (1 + 3) * 2 + 1)

First, let’s try it in Jruby:

 irb(main):002:0> (1 + 3) * 2 + 1)
 SyntaxError: (irb):3: , unexpected tRPAREN

         from E:/apps/jruby-1.1.5/lib/ruby/1.8/irb/workspace.rb:81:in `irb_binding'
         from E:/apps/jruby-1.1.5/lib/ruby/1.8/irb/workspace.rb:53:in `eval'
         from E:/apps/jruby-1.1.5/lib/ruby/1.8/irb/workspace.rb:81:in `evaluate'
         from E:/apps/jruby-1.1.5/lib/ruby/1.8/irb/context.rb:219:in `evaluate'
         from E:/apps/jruby-1.1.5/lib/ruby/1.8/irb.rb:150:in `eval_input'
         from E:/apps/jruby-1.1.5/lib/ruby/1.8/irb.rb:259:in `signal_status'
         from E:/apps/jruby-1.1.5/lib/ruby/1.8/irb.rb:147:in `eval_input'
         from E:/apps/jruby-1.1.5/lib/ruby/1.8/irb/ruby-lex.rb:244:in `each_top_level_statement'
         from E:/apps/jruby-1.1.5/lib/ruby/1.8/irb/ruby-lex.rb:230:in `loop'
         from E:/apps/jruby-1.1.5/lib/ruby/1.8/irb/ruby-lex.rb:230:in `each_top_level_statement'
         from E:/apps/jruby-1.1.5/lib/ruby/1.8/irb/ruby-lex.rb:229:in `catch'
         from E:/apps/jruby-1.1.5/lib/ruby/1.8/irb/ruby-lex.rb:229:in `each_top_level_statement'
         from E:/apps/jruby-1.1.5/lib/ruby/1.8/irb.rb:146:in `eval_input'
         from E:/apps/jruby-1.1.5/lib/ruby/1.8/irb.rb:70:in `start'
         from E:/apps/jruby-1.1.5/lib/ruby/1.8/irb.rb:69:in `catch'
         from E:/apps/jruby-1.1.5/lib/ruby/1.8/irb.rb:69:in `start'
         from E:\apps\jruby-1.1.5\bin\jirb:19Maybe IRB bug!!

Ok, again, this is complete giberish. What the heck’s a tRPAREN? Ok, now let’s try it using groovysh:

 groovy:000> (1 + 3) * 2 + 1)
 ERROR org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed,
 groovysh_parse: 1: unexpected token: ) @ line 1, column 16.
     (1 + 3) * 2 + 1)
                    ^

Ok, this is exactly what I hoped to see. A nice, clear message telling me what I forgot and what it is associated with.

Shortest. Evaluation. Ever

You may not be saying that this is a weird way to evaluate a language. Well, it wasn’t my plan to evaluate Jruby by looking at its error messages, but it was all that I guess I needed. Here’s why error message quality is important to me:

1. Based on my experiences with numerous up-and-coming scripting languages, the quality of the error messages is proportional to the quality of the interpreter. If this assumption is true in this case, then the Groovy interpreter still appears to be more mature than the Jruby interpreter.
2. Other programmers won’t know what to do when they see one of the Jruby stack traces. Even if I was able to train myself to read the Jruby stack traces, I doubt that my co-workers would have the time or inclination to follow suit.

So, once again, when it comes to my unusual needs, Groovy wins the battle of stability and ease-of-use. Before I end this post, however, I would like to say a few good things about Jruby so that I don’t appear to be partisan:

• I’m really happy that Jruby finally has a tool that will compile your .rb files into .class files. This will make it much easier for me to deploy Jruby applications in my environment some day.
• Jruby seems to be improving at a rapid pace, and it has a lot of support from companies such as Sun. I think that it will be stable enough for my needs within a year or so.

I am about to finish my first non-trivial application written in Groovy (a medium-sized suite of administrative scripts), and so far I’m pretty happy with the language. I thought I would share some of my notes in case anyone else is considering the language for a similar application.

Development Environment

One nice thing about Groovy is how well it works with a system administrator’s “toolbox” of applications, i.e. a text editor and command shell. The development tools that I specifically used were Vim, the command shell, and ant, and I found the pace of development to be very rapid.

References

Since Groovy is still pretty new for me, I need to read a lot of reference material. Here’s the resources that provided the most value:

• Groovy In Action – From my own experiences and what I’ve read on the groovy-user mailing list, GINA is the best Groovy reference manual available. For me, it answered about 95% of my programming questions, with tons of great examples to boot.

Note: This book is a little expensive, so I purchased the electronic version from the Manning web site. If you’re going to be doing most of you reading on a computer screen anyways, I recommend this option.

• PLEAC-Groovy – The PLEAC project’s goal is to implement the examples in the Perl Cookbook in multiple languages. Groovy is one of those languages and I believe the first one in which 100% of the examples have been implemented. The examples are very useful and easy-to-understand, so I highly recommend this resource.

Note: I recommend downloading a copy of the PLEAC-Groovy web site using something like HTTrack or the Scrapbook plugin for Firefox. You’re probably going to use this reference a lot, so you’ll want to have quick, offline access to it.

• groovy-user Mailing List – This list is very informative, and most of the people with which I’ve interacted on this list have been very knowledgeable and patient. It is highly recommended.

Application Overview

I can’t really say much about it, other than the following:

1. It’s designed to run on a server and has a command-line interface.
2. It performs a lot of filesystem-related operations.
3. It processes a lot of XML.
4. It has a lot of unit tests.
5. It integrates with a proprietary, third-party library.

First, let me say that the Groovy feature that stood out for me the most was it’s excellent, built-in XML processing libraries. I usually hate processing XML since there’s usually so much “heavy-lifting” and debugging, but Groovy makes the task trivial.

Another feature that I didn’t even know I would like be ended up loving was Groovy’s AntBuilder class, which allows you to use ant tasks in your code in a trivially-simple way. This was especially handy when it came to filesystem-related operations. And of course, the icing on the cake is that Groovy allows me to do all of this while integrating with all of the Java libraries (both standard and third-party) that I need to do my job on a daily basis.

Gripes

Of course, such a new language is going to have a few rough spots. Here’s the ones that I encountered most frequently:

Poor Error Messages

Occasionally, you will get error messages that make no sense whatsoever. My favorite is when it told me that I had a null character on a line that didn’t exist in my document in column 0 (which also doesn’t exist). The good news is that error messages in general are pretty decent, especially when you run Groovy with the debug switch.

Non-Intuitive Behavior

I ran across some truly odd functionality that border on a bug in my opinion. When I asked the mailing list for some clarification, I learned that some of Groovy’s functionality is dependent upon the brand of JDK that you’re using. Yikes. Hopefully the Groovy developers are able to normalize these sorts of anomalies in the future. In the mean time, I recommend decent unit test coverage on any non-trivial application to ensure that everything’s working like you expect it to work.

Conclusion

Even with it’s rough spots, I found Groovy to be incredibly robust, stable, and easy-to-use. Not only did it satisfy 99% of my requirements perfectly, it provided time-saving functionality that I didn’t even know I needed. Now I’m curious to see how the end users like it

I’ve been using the Groovy programming language a lot lately at work to programmatically interact with systems that have Java interfaces. Simply put, it’s great, and it really makes my job as a sysadmin of Java middleware easier. Also, if you’ve tried other Java-based scripting languages like Jython in the past but have been disappointed (like me), then I definitely recommend that you check Groovy out.

I think that the admin angle of the language is lost on most potential users, however. Groovy is a great language for writing small-to-medium-sized administrative scripts, and it’s even a great language for non-”real” programmers who want to start dipping their toes into the pool of Java. For those who are considering whether they want to put in the time to learn a little about Groovy, here are some of the advantages that I see as a sysadmin:

No More Compiling & Building

First of all, if you’re still compiling your Java apps using javac, then stop reading this article and start using Apache Ant. You’re wasting your time with javac, even if most of your scripts are pretty small. Ant is a great tool that has saved me a ton of time, but it’s definitely not without it’s own learning curve and occasional problems, however.

With Groovy, there is no explicit compilation step, just like with Perl and the Korn Shell. You just write your script, run it, fix and problems, run your script again, and then rinse and repeat if necessary. This is a much more intuitive programming workflow for most sysadmins.

Easier Deployments

If your script is going to eventually run on a server, all you have to do to deploy it is to upload it to the server. From there, you can run it like any other Perl or shell script. You don’t have to worry about writing or deploying wrapper scripts for your class or jar files that actually invoke your program.

Simpler Syntax

Here are some of the syntactic niceties offered by Groovy:

• Like Python and the Korn Shell, Groovy doesn’t force you to end every line with a semi-colon if it only contains a single statement.
• Loose typing, so you don’t have to declare a variable’s type when you create it.
• Fewer brackets
• No forced classes
  • In Java, every file is explicitly defined as being a class. You don’t have to do this with Groovy.
• Multiple Classes In One File
  • Tired of following OO design standards that force you to create 8 separate class files for a relatively simple program? Put them all in a single file in Groovy and simplify your life.
• More features that I’m just now discovering like closures and Javabean-like accessors.

Text Editor Friendly

I was reading a blog article by a Sun developer the other day where he said that he didn’t like Groovy because it didn’t integrate very well in Netbeans (an IDE). He mentioned that there was no decent code completion module for Groovy yet like there is for Java. It therefore took him longer to write the following print statement in Groovy:

println "hello"

…than it did to write the equivalent (and much longer) statement in Java with the help of code completion:

System.out.println("Hello");

Although this statement is a little short-sighted in my opinion (“I don’t like cars because there’s no place to hook up my horse”), it points out one of Groovy’s strengths: it can be used very well with only a text editor and a command prompt. Groovy, like Perl and shell languages, was never designed with whiz-bang IDE’s in mind. It’s brief, powerful syntax and development tools were designed to make programming with it so easy that you could do it using Notepad and the command prompt if you wanted and still be very efficient and effective.

Groovy’s ease-of-use outside of an IDE is good news for most sysadmins for a couple of reasons. First, they spend a good portion of their days using text editors to do things like view log files, change config files, et cetera. Being able to use the same text editor to also write scripts lowers the learning curve and is very synergistic. Also, most sysadmins usually don’t have IDE’s like Eclipse or Netbeans installed on their system. For the type of Java programming that they typically do, they view IDE’s as being bloated and having an unnecessarily high learning curve.

Groovy Shell

One of Python’s greatest strengths is the fact that it comes with an interactive interpreter. Groovy also includes an interactive interpreter, and its major benefit is that it allows you to evaluate small snippets of code quickly and easily. This comes in handy when you’re having problems getting a chunk of code to work, and also when you’re “kicking the tires” on a new third-party library or language feature.

Conclusion

There are a lot of new scripting languages out there that are Java-based, and their potential benefits are numerous. However, it can be difficult to pick one that is worth the time and attention necessary to achieve proficiency. In my opinion, Groovy fits the bill and then some, and is especially good for people who need to write small-to-medium-sized programs that interact with Java systems.

I’ve been using Java since 2000 for a variety of tasks, mostly related to software administration and maintenance. A common request from co-workers and some of my geekier friends is a list of recommended resources for Java training.

I’ve built this list a couple of times, and I keep losing the old lists, so I thought that I would put it on my wiki so it would be a little more permanent. I hope that a few people find it helpful.

Dead-Tree Book Resources

• Just Java – The Java bible. No matter what you do with Java, you’ll need this book eventually. Not only is it very informative, it is entertaining and very well written. It’s one of those truly excellent technical books that you see so very rarely in a jungle of crap.
• Sun Certified Programmer & Developer for Java 2 Study Guide – The only book you’ll really need to become a Sun Certified Java Programmer. Also very well written.
• Head First Java – I haven’t actually read this book, but I’ve heard wonderful things about it from multiple sources, and it was written by the same authors of the previous bullet point. I look forward to reading the other books from the succesful Head First series.
• Core Servlets and Javaserver Pages – A good book for learning the basics of JSP’s and servlets. I recommend checking this book out from the library because it’s a fairly quick read. Another cool thing about this book is that there are a lot of excerpts available at http://www.coreservlets.com. Definitely check out the web site if you’re interested in this book.

Online Book Resources

• How To Think Like A Computer Scientist – This is a good, free start to programming with Java.
• Thinking in Java – This is an excellent free book for programming in Java. It’s quite possibly the best free programming book available for any language.

Web Sites

• JavaRanch – I highly recommend this web site if you are a beginning Java programmer. I feel that the following sections are particularly good:
  • Forum – I received some great support from this forum on numerous occasions, but it was especially useful when I was studying for the SCJP test.
  • Campfire Stories – Tutorials and tips
  • Bunkhouse – The best place for unbiased reviews of Java books.
  • Cattle Drive – I am a former pupil in their Cattle Drive class, and found it to be a very good educational value for beginners.
• Roedy Green’s Java & Internet Glossary – His exception page is my favorite place to go when I’m stuck on a particular error and need a little guidance. Also, it includes a treasure trove of documentation and tutorials to help you with most basic tasks. It’s an absolutely essential resource.

Note: Please note that I linked to Amazon for all of the books listed above, but I’m not getting a kickback for doing so. You should be able to find a lot of these books at your local library, and they should all be available from discount book sites such as half.com.

Good luck and have fun!