How stable is the Groovy language?

Question

We're writing a large production system in Java, and I'm considering whether or not we can write some of the components in one of the JVM-based dynamic languages. Groovy appears to be the best choice from the Java interoperability standpoint. But is the Groovy implementation reliable enough to use in production (I would assume so), and is the Groovy language specification itself stable enough so that we aren't going to have to revise our production code substantially in a year or two? What are your experiences?

Summary (5/30): Good comments, the sense I get is that you should be cautious in adopting Groovy for mission-critical production use, it's fine for ancillary usages like putting together test cases, and there's a middle ground where it's probably fine but do your homework first. Performance is an issue, which needs to be balanced against the increase in developer productivity. Bill and Ichorus have equally helpful answers based on Groovy use, so it was a coin toss.

Update (12/3): More recently I've been taking a serious look at Scala, another JVM language. It was designed and implemented by Martin Odersky, the original author of the current javac compiler and the co-designer of Java Generics. Scala is a strongly typed, but uses type inferencing to strip out a lot of boilerplate. It's a nice blend of object-oriented and functional programming. James Gosling likes it. James Strachan, the author of Groovy, likes it too. And Odersky's experience writing javac means Scala's raw performance is not far from Java's, which is impressive.

Answer 1

Scripting languages evolve "too fast" in the aspect of syntactic features.

If you want a language for the JVM that will stay compatible for many years,
Java is your only choice ;)

By the way, I don't think that the readability of code is ensured by a scripting language automatically.

Answer 2

I've been using groovy to support production applications for a while and for that purpose it is stable enough. As for actually having Groovy in bona fide production code; I don't think I would do that. Groovy does too many surprising things. It has gotten much better in this regard over the past year or so, but every once in a while I will run into a bug that is a bit difficult to track down because of the generated code ( my issues seem to have revolved around scoping). I have gotten away from groovy (though the stuff that we use that is simple and solid is still around) and have used python (jython implementation) which has been far more predictable in my opinion. Also, python trumps groovy in readability. You can write some very interesting code in groovy with closures and operator overloading and whatnot. These languages are used for convenience and speed on ancillary code...stuff that can be switched out on the fly if need be. None of it is in production. I don't think I would put either in production unless it was as a stop-gap to get something critical out of the door in a major hurry or as a proof of concept or prototype. And in the case of putting it in actual production, it would have to be in the most dire of circumstances and I would assign someone to re-write it in pure Java for the next release. I am 98% sure that either would be fine in production but that 2% is too much unnecessary risk.

Answer 3

We've got several production apps running on Grails (using Groovy as the language). So far, no issues have resulted. As for JVM compatibility, take a look at how little the JVM byte-code has changed in the last 5 years... like 1 instruction was added, and none were made obselete.

Will new versions of Groovy come out in the next year? Yes. Will you be required to change to them? No. Though you might want to, 1.6 is a huge speed improvement.

Which brings us to the major drawback of Groovy, the speed issue. Obviously, Groovy is slower than straight Java. The current number are up to 10 TIMES slower, for certain actions. That said, is your CPU the bottleneck in your app? For us, it's mostly DB access and latency. If it's the same for you, what matter if the CPU spends 200ms processing the page request instead of 35ms?

Is that the only problem with Groovy? Nope. Dynamic languages have refactoring difficulties, since there isn't necessarily a complete class specification anywhere in the code. However, this is partially balanced by the smaller code-size which makes it easier to find the places to modify the code.

Anyway, Groovy is a perfectly fine language for production uses. Mix it with Java for your "critical" code, if you fear the reliability. That's the BEST part of Groovy... how easy it mixes with Java classes.

Answer 4

I'm currently exploring using groovy for only writing unit tests. This has the effects of

1. Allowing the potentially tedious part of writing tests to be done in a syntax that is a bit simpler than java.
2. Keeps the groovy code out of production.
3. Allows a large portion of the code base to be written in a non java language.

Of course, we haven't started yet, but this is at least my way of attempting to introduce alternate jvm languages to our new projects (and possibly existing ones). I have the same concerns you do, and even more so around performance than stability.