Why the Advance in JVM Languages Recently
Scripting languages have picked up in the last 2–3 years as developers try to find simpler ways to write code. In general, Java presents developers with numerous advantages – it’s powerful, fast, has a huge community behind it, and there are lots of open source projects written in it. But Java tends to be very heavy and is not ideal for solving lightweight problems. Scripting languages, on the other hand, have been making headway in the last couple years because the hardware is now fast enough to run them well. They’ve always been slow relative to Java – easily 10 or more times as slow. Now, with much improved interpreter performance and modern hardware, implementations of Python and Ruby are beginning to capture the attention of even die-hard Java fans.

In the last couple of years, we have crossed the threshold where dynamic languages went from slow and ineffective to a viable solution. They are becoming so good, in fact, that Java developers are thinking of jumping ship. Consequently (and the reason for the advancement in dynamic languages for the JVM), Java developers have been experimenting with dynamic languages and so far, seem to like what they have found. But it’s tough to give up the wealth of Java knowledge most of these developers have accumulated and become accustomed to over the years. Where these JVM languages come in is that they preserve the experience Java developers have but also allow for the benefits that scripting languages provide.

Displaying great foresight, Sun has launched a full campaign to develop the JVM to stem the tide of people leaving Java. This is why Sun brought on Charles Nutter and Thomas Enebo, two of the core JRuby developers, to work on JRuby full-time in late 2006 and recently hired Frank Wierzbicki and Ted Leung in March 2008 to do the same for Jython. I wouldn’t be surprised if in the next couple of years they grabbed some Groovy gurus too. It’s a smart move on Sun’s part to keep people on the Java Platform, even if they want to write code in a different language.

One of the real wins for these Java-based scripting languages, as opposed to a C-based alternative, is the Java Virtual Machine. The JVM runs everywhere. It’s fast, powerful, portable, and well supported. Plus, Sun will probably enhance it considerably next year, as they have for the past 12 years, which means your code can get faster, use less memory, and scale further without ever touching it. There’s really nothing as sophisticated or robust as the JVM.

So…Which One?
If I were to rate JRuby, Jython, and Groovy in terms of integration with existing Java code, I’d have to say that Groovy is the most robust, JRuby is the next strongest, and Jython lags behind. The recent Sun hires may turn Jython around but my guess is that Jython is at least six months to a year away from being used in serious production deployments.

Jython is similar to Python. And Python is a pretty different language from most others. The sticking point for many people is the way you write the code – space actually matters. White space, ignored by almost all other programming languages, is significant in Python. Most people either love it or hate it, though I’m in the middle. It’s a characteristic that is unique to Python and that Jython picks up. In addition, there’s a bit of an impedance mismatch between Java and Python. The conversion process around basic collection classes and other primitives when integrating with Java seems to be a bit clunky. It’s just not completely smooth – it gets in the way a little more than it should.

In JRuby, conversion is considerably easier. You can convert back and forth very nicely, so you have little to fear. In my view, Groovy is even easier to use than JRuby and works more seamlessly with Java. I sometimes joke that Groovy is simply a “fancy Java.” This is because Groovy is written in Java, uses all the same classes, and has no gaps. All of these features are readily apparent in the language.

Essentially, there’s no simple answer as to which one is the “best” language. If I were to write some quick scripting task that needs to use Java in a non-trivial fashion, I’d almost certainly go with Groovy. If I were to use a lot of native facilities, such as manipulating files or directories, and needed to get a little down and dirty with the details of operating system–specific facilities, I’d go with JRuby. This is because Ruby has a deeper linkage to the platform you’re on, whereas Groovy only has Java-level tie-ins.

JRuby has recently done a lot to overcome most of its problems integrating with Java. It’s not quite 100 percent there yet but I have no doubt the core developers will be able to smooth out the process this year. I think they can get it to the point where it’s almost as good as Groovy almost all the time, but I don’t think it will ever be able to attain the same level of seamlessness as Groovy.

My Experience with These Languages
At OpenLogic, we sell an open source governance platform that includes a certified library of open source packages. As a result, we have insight into what Fortune 500 companies and their developers are doing. I’m seeing Groovy starting to show up in more deployed applications. This is primarily because it’s getting embedded in other production open source projects, which means Groovy scripts to query and maintain these systems are also making their way into production. JRuby and Jython are probably on their way too, but a bit slower.

In my experience at OpenLogic, it seems like a particularly good fit between Sun’s NetBeans and JRuby. NetBeans is currently the best IDE for JRuby and Ruby development, thanks to advanced code completion, built-in knowledge of Rails, and Java integration. JRuby integrates well with almost all Java libraries, but, oddly enough, JRuby does not integrate as well with some Ruby libraries because they contain native C code, which is naturally harder to integrate with the Java-based JRuby. It’s not a major drawback though because today there are so many options in the Java space that you can typically find an alternative to most Ruby-based libraries that depend on native code.

Summary
Through my work at OpenLogic, we have deployed what might be one of the largest, most widely deployed enterprise software applications using Groovy. One of our largest corporate initiatives in 2008 is built on JRuby. We are agnostic about all of the open source software packages in our certified library that we offer to our clients. But I can tell you from a developer standpoint, scripting languages are here to stay.