Open source software, while not synonymous with Java, may often be seamlessly integrated with Java code to produce a versatile synthesis that makes developers’ lives much easier. In recent years, developers have taken some open source dynamic languages, commonly referred to as “scripting languages,” and adapted them to the more mainstream Java platform. This allows the new hybrid language to maintain its scripting qualities, while being fully utilized by a Java program. Three of the most prominent open source/Java languages are JRuby, a Java implementation of Ruby; Jython, a Java implementation of Python; and Groovy, an object-oriented programming language for the Java platform.
JRuby, Jython, and Groovy
Before I go into my thoughts on JRuby, Jython or Groovy, let me provide a quick background on myself. I have been using Java since 1996 (it was first released in 1995). I am a Sun-certified Java Architect and have significant Java experience. Moreover, I have spoken at JavaOne a handful of times and will be speaking there again in 2008 on JRuby and Groovy. I have worked with JRuby and Groovy extensively – in fact, at OpenLogic, we used Groovy to build OpenLogic Enterprise, a technology platform that enables businesses to deploy, manage, and control commercial-grade open source infrastructure. We had more than 100,000 lines of Groovy code deployed in the product. We also wrote OSS Discovery, a tool enterprises use to find up to 900 of the most commonly used Java-based development tools, libraries, and server applications in JRuby.
In my experiences, dynamic scripting languages make it easier to write code in many situations. Scripting languages are much more human friendly than, say, C++. They lack all of that meticulous syntax. With dynamic languages, I am freer to do what I want – I can proceed without thinking as much about the nuts and bolts that go into the code. The fact that Microsoft is also getting involved with IronPython and IronRuby for their .NET framework only goes to show that these dynamic languages are significant and valuable. It validates the idea of incorporating dynamic languages – they are here to stay.
In my view, the fact that some scripting languages are based on the Java platform makes them better. They enjoy all the benefits of scripting languages like Ruby and Python, but also provide a very intimate bi-directional interface with Java. They present the developer with the ability to code, test, and debug quickly and efficiently while also harnessing the abilities of the Java platform. Another plus of Java-powered dynamic languages is their ability to leverage thousands of open source libraries written in either their “native” language or in Java. JRuby, Jython, and Groovy incorporate all of these goodies into nice, neat packages.
JRuby allows the embedding of the Ruby interpreter into any Java application with full two-way access between the Java and Ruby code. As such a fusion, it maintains the scripting qualities of Ruby while being tightly integrated with Java, and can be called directly from Java programs. Jython provides similar capabilities around Python. Groovy, unlike JRuby and Jython, is not derived from a foreign language. Rather, it’s loosely based on features from Ruby, Python, Smalltalk, and other languages, but designed from the ground up by Java developers for Java developers. Needless to say, it works well with other Java code and libraries, but is also a powerful scripting language in its own right.
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.