Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

OK, so there are quite a few people using Java these days. But as the language nears two decades of age, it isn't exactly the coolest option out there. Many of us are excited about dynamic languages with some functional features like Ruby or Python, even though we spend our days using Java.

So why is it that the adoption of Groovy has been so slow? It seems that Groovy offers much of the benefits of Ruby and Python, but it is far easier to transition a Java shop to Groovy. Even if performance were the concern, it seems that many would want to use Groovy for testing the production Java code. Or use Groovy/Grails for internal apps in which performance concerns are minimal. Or for writing one-off scripts to generate code.

Yet Groovy languishes outside of Tiobe's top 50 languages, for reasons that are unclear to me.

I have been using Groovy and Grails professionally for about four months, and it has been an excellent experience, such that I hate to think about going back to the Java/Spring/Hibernate model.

Does anyone have any sense on why we are not seeing more significant migration from Java to Groovy?

Note that I'm not asking why Java developers are still using Java for new projects. My question is: Why is it that most Java Developers are still not using Groovy at all.

Edit: I am assuming that all good developers see the utility of dynamic typing and higher order functions for some programming tasks. (Even if it is deemed inappropriate for production code.)

share|improve this question

closed as not constructive by ChrisF Jan 30 '12 at 22:53

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. If this question can be reworded to fit the rules in the help center, please edit the question.

Not all people are fans of dynamic languages! You are implicitly assuming that dynamic languages are always better than statically typed ones. I personally see Scala as a more viable alternative than Groovy. –  LeakyCode Dec 15 '10 at 12:39
Python is several years older than Java (1991 vs 1995, according to wiki) but it's imo as far on the cutting edge as a traditional imperative/oo/multiparadigm language can be. It's not a functional language however. –  delnan Dec 15 '10 at 15:15
Python is older than Java, but it's popularity is newer. And it's far more functional than Java. –  Eric Wilson Dec 15 '10 at 15:24
Don't cite TIOBE. It is meaningless. Having said that, I'm with Mehrdad here: Scala is a much deeper improvement over Java. The inventor of groovy himself said, that he wouldn't have invented groovy, if scala has been out there then. :) Groovy isn't compiled, is it? –  user unknown Feb 13 '11 at 1:18
TIOBE is messy but not completely meaningless. Groovy is still outside TIOBE's top 50 in March 2013, over two years after the OP's comment on it. –  Vorg van Geir Apr 3 '13 at 13:41

14 Answers 14

up vote 12 down vote accepted

Here my reasons:

  • dynamic typing: Yes, it's the reason for many to prefer groovy. but static typing has it's advantages, i.e. in readability.
  • performance: In my experience some groovy-applications are significantly slower than java-apps.
  • PermGenSpace: We had problems with PermGenSpace-Errors using grails-webapps on Tomcat. Maybe less an Groovy and more a Grails-problem, but we develop webapps mostly.
  • compatibility: Also an Grails-problem. We had difficulties to update an project to newer grails-versions. To setup a server with different apps, we had to go in the end with webapps with different Grails-versions.
  • Years of experience with Java.
  • Great tool-support for Java, lesser for groovy.

OK, some of this is related to Grails. But developing webapps, Grails is important if you want to use Groovy.

share|improve this answer
There are a few differences between static and dynamic typing you can state objectively. "Readability" is none of these. Many would claim that explicit type annotations are just clutter for the most part (and they'd still miss the point, because manifest typing != static typing). –  delnan Dec 15 '10 at 15:17
Regarding PermGenSpace: Class definitions go there almost immediately, and if Groovy/Grails is constantly regenerating classes it will eat up your PermGenSpace quickly. Same issue with recompiling JSPs during development, but those run sessions are short enough most folks don't run into heap errors. –  Berin Loritsch Dec 15 '10 at 15:25
if the type of a variable/parameter/function is explicit the code is easier to understand. If not, you have to figure out, what inputs are allowed. Maybe that is documented, but with explicit types that is unneeded. That's why readability. –  Mnementh Dec 17 '10 at 16:33

I am a java developer, the reasons I am not using Groovy are:

  • It's dynamically typed
  • When I search for a job on a popular recruitment webiste there are 11,000 Java jobs, and only 11 Groovy jobs.
share|improve this answer
My question isn't why you aren't programming full-time, but why you aren't incorporating Groovy in to your Java job. –  Eric Wilson Dec 15 '10 at 12:32
Thats what I answered. I would only incorporate something into my job if it would be beneficial to my career prospects. Groovy, imho, is not. –  NimChimpsky Dec 15 '10 at 12:34
Ah. I was thinking you would incorporate it into your job if it was a tool that would help you get things done faster. –  Eric Wilson Dec 15 '10 at 13:03
@Nim surely you aren't that cynical?! Would you ever choose a tool that would help productivity in or satisfaction with your current job, rather than just future career prospects? –  Alison Dec 15 '10 at 13:15
@NimChimpsky It's really hard to measure, but a combination of jobs, blogs, tweets, books, conferences, chatter, IDE support, solar winds, size of community, mailing lists, forums, SO, chicken entrails etc that all mention X. But in reality I only have the 1500 or so developers in the London JUG to go on, and a hefty percentage of those I've talked have at least got some sort of Groovy script or embedded JAR running somewhere. –  Martijn Verburg Dec 15 '10 at 14:04

Having done quite a bit of Groovy programming and given it a "good go" I now prefer the "pure Java" approach for the following reasons:-

  1. Debugging -- the debugger walks you through tons of internal groovy code. I know there are some options to filter this out but they are far from perfect and either don't filter out all the internal code or skip over some of your own code.
  2. Code Completion -- very useful when using java classes totally useless when using groovy (at least under Eclipse).
  3. Deployment -- while its quick and easy to hack up a groovy script inside Eclipse or some other IDE putting together a working Jar file you can give to someone else to run is painful.
  4. Its slowwwwwwwww.
  5. Verbosity does not equal work. While Java code is more verbose it doesnt actually take that much longer to code up. Groovy's terse syntax is sometimes harder to understand as more things are defaulted and/or implied which means reading the docs to find out whats happening rather than have it coded up in front of you.
share|improve this answer
+1: "While Java code is more verbose it doesn't actually take that much longer to code up". I totally agree: sometimes having a language with a simpler and clearer semantics, a clear class design and coding style increases the productivity much more than having a terse syntax. I am much more productive in Java than in C++ and, unless I need some special library that's only available for C++, I only prefer C++ when I need high performance. I haven't tried Groovy, but since it is dynamically typed I would not use it for large projects. One has to look at all aspects that influence productivity. –  Giorgio May 19 '12 at 7:37
Too be fair to Groovy -- items 1 and 4 in my list are vastly improved in the latest release. Debugging is now much cleaner, and you have options to staticly type variables, effectivly, turning of the dymamic typing where you don't need it. –  James Anderson Apr 3 '13 at 1:47
In the mean time I have tried out a few dynamic languages (Python and Scheme) and I see that I can work with them pretty well. But again, if I had 200 000 lines of code to maintain, I still think I would prefer them to be written in a statically typed language. –  Giorgio Apr 3 '13 at 8:51

I'm not using Groovy because I don't see the need for it. Seeing as it is run on the JVM and I already know Java pretty well, why would I invest my time in something that is pretty much the same anyway.

But I realise that I can't be a one trick pony for my whole career. That's why I have started to learn Python. When I was looking for a new language to learn, I did think about Groovy, but the similarities to Java made me think twice.

But you also have to look at what other people think of Groovy and the one point that keeps popping up when I think about Groovy is that the creator of Groovy said he wouldn't have bothered if someone has shown him Scala. I think this shows that Groovy isn't really a real alternative to Java or even a realistic addition to Java. If you want something that runs in the JVM, use Scala.

share|improve this answer
Folks! 'the creator of Groovy said he wouldn't have bothered if someone has shown him Scala' does not imply that scala is better than groovy! –  rdmueller Aug 4 '11 at 18:26
I think it definately implies scala is better, it just doesn't prove it's better –  Kevin Aug 5 '11 at 3:49
@Kevin: It implies nothing of the sort. –  Josh K Aug 5 '11 at 4:58
@Josh: to me it implies that it solves the problems Groovy was intended to solve at least as well as Groovy does - in the eyes of the guy who created Groovy, and who could judge that better? –  Michael Borgwardt Aug 5 '11 at 7:55
Good enough can be an enemy of great. If good enough exists, very few people will go on to make great. –  Bill K Apr 2 '13 at 19:08

It's somewhat an egg-and-chicken problem. A language that has little momentum gains little users, and thus has little momentum... There's lot of competition to choose from, and Groovy hasn't quite caught the attention like some others have. I think lots has to do with productization, starting from the web site:

  • Groovy website. It's in a subdomain of a German(?) open source community site (no own domain), contains some cheap-looking Google ads, and has a somewhat amateurish looks overall.
  • Scala website. Pro.
  • Python website. Pro.
  • Ruby website. Pro.
  • Jython website. Cute, amateurish looks, functional but scattered documentation (a wiki), and another language that has been around for a long time but hasn't quite gained momentum. A coincidence?
  • etc.

While the superficial appearance of a web site has absolutely nothing to do with the goodness or usefulness of a language, it may have quite a lot to do with catching attention, maybe subconsciously, when there are lots of good competitors around, and the differences like "which is better by some absolute measure" are not obvious. Furthermore, the effect of momentum squares these differences.

share|improve this answer
Well codehaus maybe a german(?) open source community, but they are well known for good and robust products... In this case we should also drop every bits coming from Jakarta: tomcat is hosted on tomcat.apache.org!!! Also I don't see google adds on the groovy site and groovy is strongly related to spring for some monthes now... I really can't see the amateurish look on the home site. So -1 –  Guillaume Dec 15 '10 at 14:07
@Guillaume: I didn't say being open source community brand is bad per se (I'm using xstream.codehaus.org myself!), but Codehaus is not nearly as well-known as Apache, and besides, being independent brands could be better for some Apache projects too. The Google ads are right there on Groovy's front page, about 200 pixels from the top, whole page width, where it says "Ads by Google" (or: maybe they're localized to some countries only, but I do see them very well). Don't shoot the messenger: I'm not dismissing Groovy, I'm just pointing out what may be some reasons for it not doing very well. –  Joonas Pulakka Dec 15 '10 at 14:36
In fact it's very much this kind of attitude: "There's nothing wrong with it!! Because I don't see anything wrong with it!!!!" that can break an otherwise fine product's success. An arrogant culture that only deals within itself can't compete with a friendly, feedback-seeking culture. This is probably not the case with Groovy, though. –  Joonas Pulakka Dec 15 '10 at 14:57
I hadn't thought about this, but yeah. If you compare the websites above side by side, Scala, Ruby, and Python do appear more professional. Not sure how that relates to the populatity of the language though. Regarding tomcat, that looks more professional too. I don't know if it's relavent, but both Jython and Groovy use green heavily (in Ireland, weirdly enough, that's considered a bad luck colour [except on Paddy's day, that is!]) –  GKelly Feb 18 '11 at 14:16
Ruby's official website is so out of date. rubyinside.com/official-ruby-site-not-so-good-5248.html –  Chiron Aug 5 '11 at 2:24

For me the answer is tool support. There is tooling for Groovy but its not as good as Java.

Poor tooling is why I haven't done much Scala, Clojure etc as well.

However, if you need to write a program to extract some stuff from XML, filter it and write it to a database... Groovy is very very good at these tasks.

There are some big websites that are Grails (and hence Groovy based). E.g. sky.com (UKs biggest satellite TV provider)

share|improve this answer

I spent a bunch of time evaluating the different JVM languages. Groovy is really nice and well designed but the things I didn't quite like were:

  • Too dynamic - it clearly wasn't going to be possible to write highly optimised code, which was one of my requirements
  • Still focused on the OOP paradigm

I eventually picked Clojure.

  • It's also dynamic by default, but allows static typing through type hints if you want, which gets much better performance
  • It represents a real paradigm shift in terms of concurrent, functional programming that I'd argue is hard to achieve in any current OOP language
  • The parentheses are actually awesome once you get the hang of them
share|improve this answer
I'm curious how Scala compares to Clojure, in your estimation. –  Eric Wilson Apr 14 '11 at 22:48
+1 for "The parentheses are actually awesome once you get the hang of them". –  Chiron Aug 5 '11 at 2:26
@FarmBoy: In my view Scala is great and works well if you want a Super-Java. Clojure is less mature but amazingly designed and a real paradigm shift (to where I think languages should be going, esp. around concurrency, functional programming, meta-programming etc.). Both are suitable for real world use and have a strong community, so I think it really depends on your level of comfort with functional programming and the extent of your desire to get "ahead of the curve" –  mikera Aug 5 '11 at 10:14
I liked Scala until I started using Clojure... :-) Groovy doesn't even make my list... –  Brian Knoblauch Oct 6 '11 at 19:39

Back when I did Java development, I didn't use it for one of the worst reasons: the name. Now before anyone reaches for that downvote button, it wasn't my decision. I wanted to use Groovy and Drools for a project I was working on for a long term client. My project manager refused to allow us to use Groovy or Drools because he said he'd feel like an idiot telling the client we were using technology with such unprofessional names. It was unfortunately a requirement that the client signed off on the inclusion of any new technology (understandable since they were the ones who were going to maintain it after delivery) so without the PM's support, I simply couldn't make use of it.

share|improve this answer
Good point. I often feel like an idiot mentioning the names of some technologies, especially in front of non-technical people ! Sure you could argue that the name shouldn't be an important criteria, but at some level the name can have an impact. –  Antonio2011a Oct 6 '11 at 22:27
You think "Groovy" is bad? Try talking about Groovy's "G-Strings". You'll get more than clients not signing off, you'll get the female programmers threatening lawsuits! Enough for any IT manager to go with Ruby instead. –  Vorg van Geir Sep 9 '12 at 2:11

Dynamic vs static is pretty much the compelling argument here. There was a great shift towards dynamic languages for a while due to the 'success' (popularity) of Ruby and Rails. Take a look at the Google trends and I believe you'll see that popularity has peaked and is dipping once more.

Dynamic languages aren't/weren't the silver bullet. For many of us static languages are just simply safer to use and have proven to be more scalable and robust (for now).

That said I love my dynamic Groovy console that monitors my PRD runtime app server/JVM and I firmly believe that [shameless plug]The Well-Grounded Java Developer[/shameless plug] of the future will use several JVM languages to their advantage.

share|improve this answer
Certainly some interesting trends! google.com/… (terms picked to avoid homonyms) –  Alison Dec 15 '10 at 13:17
@Alison Thanks for that (I was lazy) :) –  Martijn Verburg Dec 15 '10 at 14:00
If scalability and robustness are the strengths of static languages, what are the major strengths of dynamic ones? Speed of implementation? –  Alison Dec 15 '10 at 17:12
@Alison For me yes - but the crucially (again for me only, I can't speak for others) this is only really true for small systems/prototypes. Once it hits a certain size then I don't find it any faster than say, Java. –  Martijn Verburg Dec 15 '10 at 17:23
@Martijn slightly off topic, but do you think a statically typed alternative to JavaScript would be a good thing? –  Alison Dec 15 '10 at 17:30

The JAR is 5MB

I've had problems justifying including Groovy in a couple of projects because of the sheer size of the library required.

This is unfortunate, but I do understand why size is not a priority for the Groovy developers at this point.

share|improve this answer
I'm not sure why this bothers you. –  Eric Wilson Dec 15 '10 at 14:35
Because it bothers my users. –  Alison Dec 15 '10 at 14:36
Because the download is big. –  Alison Dec 15 '10 at 16:17
5MB was a big download in 1999. –  Kaleb Brasee Feb 26 '11 at 18:15
Java's standard library is larger than 5 MB. –  alternative May 22 '11 at 18:46

It's been nearly a year since I asked the question, and my views have changed a bit. Now I'm one of the Java devs that is not using Groovy.

Here's my answer to the question: http://wilsonericn.wordpress.com/2011/09/13/why-my-code-is-rarely-groovy/


  1. Groovy is a compromise
  2. Groovy feels like a hack
  3. Groovy has (in practice) a narrow problem domain.
share|improve this answer
Groovy has been "repurposed" so many times. It was started as a Beanshell alternative by James Strachan. Graeme Rocher then took it over, added a meta-object protocol (MOP), and used it for Grails, a clone of Rails. Guillaume Laforge then removed the parentheses and dots from the method call syntax and peddled Groovy as a "DSL". Alex Tkachman then created a statically-typed plugin called Groovy++, which was then cloned by SpringSource employee Cedric Champeau and marketed as "Groovy 2". Who only knows what Groovy is going to turn into next? –  Vorg van Geir Apr 3 '13 at 13:29

I have to use Groovy because I like Grails so much. Not to disdain Groovy but IMHO, it lacks the personality and charisma as Scala, Clojure or Forrest Gump.

I really wish if Grails supports JRuby instead of/in addition to Groovy but that will happen in my day dreams only.

Don't wake me up...

share|improve this answer
I wouldn't be surprized if Forrest Gump wrote some parts of Groovy - that would explain a lot! –  Vorg van Geir Apr 3 '13 at 13:31

A quantifiable data point: for my pet project nikki I'm using a mix of currently 65% Groovy and 35% Java. There are two reasons for the Java parts:

  • Performance - Groovy can suck badly when it starts doing all math via reflection on BigDecimal objects...
  • Tool support: when you're using an unfamiliar API, eclipse's code completion is invaluable, and idiomatic Groovy necessarily cripples that.
share|improve this answer

GWT translates from java to javascript. Therefore I cannot use GWT for groovy.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.