23

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/09): 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/09): 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.

Update (4/26/11): Take a look at Groovy++, a statically typed extension of Groovy, which has performance equivalent to Java. Looks very interesting.

Jim Ferrans
  • 30,582
  • 12
  • 56
  • 83
  • 4
    How do you define "reliable enough"? What criteria are you looking for? How do you define "stable enough"? What features are you planning to use? – S.Lott Apr 26 '09 at 23:48
  • Good clarifying questions. "Reliable enough" means extremely high quality in the bytecode generation, and few errors in the core libraries (these would need easy workarounds and be well-documented). "Stabile enough" here refers to the Groovy language specification: is the code we write today going to need substantial portig when later versions of Groovy come out? Let's set the domain of needed features to be those discussed in Koenig's Groovy in Action. Lots of good feedback here, thanks everyone! – Jim Ferrans May 02 '09 at 07:19
  • 1
    About performance, please take a look at Groovy 2.0: http://java.dzone.com/articles/groovy-20-performance-compared – Wanderson Santos Sep 02 '12 at 05:33
  • 1
    @Wanderson That article talks about the statically-compiled mode of Groovy which, although much faster than Groovy's dynamically-compiled mode, [is still very buggy](http://stackoverflow.com/questions/14774709/groovy-2-1-0-weird-behaviour-of-switch-case-break-statement-with-compilestatic). It was written by one developer within the past year, and shouldn't be compared with Scala, whose lead developer, Martin Odersky, has decades of compiler authoring experience, including on Java itself. Groovy can be reliable (dynamic mode) or fast (static mode), but not both. – Vorg van Geir Feb 20 '13 at 00:37
  • As much as I like Scala, some might not consider it "stable" when it has repeatedly broken compatibility with new releases. http://ceki.blogspot.co.uk/2011/08/is-scala-trustworthy.html – vegemite4me Jul 15 '14 at 09:49

6 Answers6

20

Edit: Here almost four years later and Groovy has become much more solid.

I can wholeheartedly recommend it for production grade projects.

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 awhile 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 stopgap 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 rewrite 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.

cdeszaq
  • 30,869
  • 25
  • 117
  • 173
Ichorus
  • 4,567
  • 6
  • 38
  • 46
  • Thanks Ichorus, these are helpful comments. I think we'll try it for unit testing for now (though I'd love to have its terse syntax for coding up Java Bean classes). – Jim Ferrans May 29 '09 at 06:32
  • 1
    I'm downvoting because this answer was made in 2009, and is less of an argument now that groovy has had more time to stabilize. There are thousands of projects using it in production today, mostly through the grails framework. – Dan Tanner Feb 12 '13 at 03:34
  • 1
    @Dan Those 1000's of projects in production (via Grails) use the (slower) dynamically-compiled Groovy, not the more recent statically-compiled Groovy, which, although faster, isn't production-ready. – Vorg van Geir Feb 21 '13 at 10:18
  • 1
    @VorgvanGeir To your point, Groovy 2.0 includes both static compilation and InvokeDynamic support. And Grails 2.2 uses Groovy 2.0. I don't discount potential considerations about performance or better fits for certain problems, but the original question was primarily around stability. My point was that Groovy has greatly matured since 2009, and a critical mass of people are successfully using it in production today. – Dan Tanner Feb 21 '13 at 22:17
  • 2
    @Dan I agree. I've edited the post to reflect my feelings on Groovy these days. – Ichorus Mar 04 '13 at 16:24
17

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.

billjamesdev
  • 14,554
  • 6
  • 53
  • 76
  • Thanks Bill, this helps. Another nice thing about Groovy is that its a great place to prototype new ideas for future Javas. On another thread Joshua Bloch's Collection Literals Proposal (http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/001193.html) was mentioned, and it seems partly inspired by Groovy. – Jim Ferrans May 29 '09 at 06:32
5

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.

Jim Ferrans
  • 30,582
  • 12
  • 56
  • 83
whaley
  • 16,075
  • 10
  • 57
  • 68
4

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.

ivan_ivanovich_ivanoff
  • 19,113
  • 27
  • 81
  • 100
  • 1
    why was this downvoted? It fits the original question with respect to stability and compatibility. This is a valid opinion, if you want to create an application that should last the next 3-5 years and still have to "customize" it in the meantime, from aspect of pervasiveness, stability, support, workforce, IDE support, profilers, etc. the most obvious choice on the JVM is still Java. Of course, for unit testing, glue code etc. there are great choices of languages on the JVM, like Groovy, Clojure, Scala, whatever. – Ice09 Oct 11 '11 at 07:55
  • 3
    I've used Groovy as primary language since 2008 and never got any problem about evolution, on the contrary, the syntatic features is just what made me very productive - and very sad when I need to use Java language. So it was just your guessing based on other languages experiences and not true with Groovy. – Wanderson Santos Sep 02 '12 at 05:32
  • 1
    Although this is true--Groovy is remarkably stable because it tries fairly hard to support Java code. The other problem is that language stability is very under-appreciated until you've had quite a few years under your belt; and even then there are a lot of situations where it simply doesn't matter and the better tool may be a language that evolves quickly to take advantage of new technology. Generally though I agree that stability is very important and the best language to get it from is Java. – Bill K Feb 01 '16 at 23:51
1

We used Grails/Groovy as our primary backend at my previous company, and from that experience I'd say that I would choose Groovy over Java in most circumstances I am likely to encounter, since it interoperates with Java seamlessly and is otherwise more fun and expressive. Additionally I would expect the database would almost always be the bottleneck of my application rather than language performance, and we didn't encounter any stability issues/bugs with groovy as far as I recall.

But personally it's usually not about Groovy vs Java for me in most cases -- it's about Groovy/Java + available libraries vs. other languages like Python/Jython/JavaScript/Ruby + available libraries. And there are a lot of other considerations there such as strength of community, maturity of relevant technologies for your particular application, etc. In particular, for web development, Grails was decent, but the community seemed lacking. My overall opinion is that I would use python or Node.js going forward. If I needed the JVM I'd use a jython-compatible python web development environment.

mindthief
  • 12,755
  • 14
  • 57
  • 61
  • I agree that Groovy is a lot more fun than java and for that reason I've been using it quite a bit--but honestly for team production code "Fun" in coding is actually a negative, it immediately implies "Unreadable". – Bill K Jul 17 '12 at 15:25
  • It is 2018 now. 6 years have gone by. You stand by that answer after 6 years? – Aggie Jon of 87 May 23 '19 at 17:01
1

I've been playing with Groovy for a month or so. The simplicity is awesome, and the dynamic language features are really cool too. However, speed is definitely an issue. Also, the groovy console really sucks. You cannot do things that you can do e.g. in python. Every once in a while I have to restart the console, reimport, things, etc. It also keeps forgetting the values I put in the variables while in the console mode; somehow mystically they go out of scope. (Is it because of the JVM? I don't know.) I cannot come up with an example from the top of my head, but the behavior I get in the Groovy console is different from the behavior I get in the Grails console, and is different from what I get by just writing code in a script.

A few more warnings. Note that Groovy is almost, but not 100% compatible with Java. For example, this will not compile:

public class HelloWorld {

    public static void main(String args[]) {
        System.out.println( "Hello, world!\n");
    }
}

Also take a look at How to get classpath in Groovy?

Community
  • 1
  • 1
Sergey Orshanskiy
  • 6,794
  • 1
  • 46
  • 50
  • My experiences with Groovy, debugging a decent sized older application, have been miserable. From what I see writing code is easier than fixing it in this langauage. I recognize most of my problem is that I am not properly trained in the language and just trying to debug someone else code. What frustrates me is the horrible lack of error handling with messages that are really not useful and not real debug until run time. – Aggie Jon of 87 May 23 '19 at 17:00