Link Details

Groovy 1.7.3 is out, on the shelves, ready to be unleashed in your projects! You can download Groovy at the usual place: (Note that you can also live on the edge these days, as we now publish regular snapshots of Groovy 1.7 and 1.8 automatically, as explained further down on the Download page)

Posted by aalmiray  |   Jun 15 2010 / 02:13

Add your comment

Html tags not supported. Reply is editable for 5 minutes. Use [code lang="java|ruby|sql|css|xml"][/code] to post code snippets.


User 226303 avatar

devdanke replied ago:

I like Groovy. It's the closest thing to Ruby while staying in the Java world. I use it and expect to use it for the foreseeable future. But I'm worried. Groovy is not staying simple. It gains more so called "features" all the time. It get's more complex with each release, but there's little extra benefit to day-to-day developers.

Why would Groovy need the Unix tr command on it's string class? If I wanted commands like tr, I'd just write Bash or Perl scripts. And what normal developer needs more AST transformation options? I'd guess at most 1%. Yet it's a notable feature in this Groovy release. I mean, how many people really use Groovy to write DSLs compared to those using it as a utility scripting language?

On the other hand, one of Groovy's glaring weaknesses remains: performance. Groovy is by far the slowest dynamic scripting language. Thankfully, the Groovy++ project is trying to address this problem. But it's disappointing that Groovy's leaders are oblivious to the issue.

(Originally from 2008, but it gets updated for newer versions of these languages.)

Performance really is a problem, and it's the same one that killed Java applets. Applets were slow to download, slow to start, and slow to run. Sun never did anything about it. James Gosling once said, "[applets] are slow, get used to it". As a result, web users got sick of them, web developers abandoned them, and Flash took over the Internet. JavaFX is one of those "too little, too late" attempts to fix applets.

Let's face it, developers and users like snappy apps. Eventually, if Groovy won't address its performance problems, developers will go with JRuby instead. JRuby has all the coolness of Groovy and then some. It takes longer to learn JRuby, because it's standard library is so different from Java, but it's relatively blazing speed can make it worth the effort. It's fast start up speed actually makes JRuby viable for shell scripting (what a concept!).

Shell scripting is really job #1 for all these dynamic languages. If they can't do that well, then they'll likely end up a niche player and won't be worth the effort to learn.

Year's ago Groovy's head honcho, Guillaume Laforge, used to promise performance improvements. But according to my tests and other benchmarks, Groovy remains about 10x slower than JRuby. I'm doubtful Groovy can ever become performance competitive with other dynamic languages while Laforge is in charge. He just doesn't seem to get the whole performance thing.

I was hoping SpringSource's 2008 acquisition of G2One would've made Groovy faster. But it never happened:-(

Nevertheless, I hope one day SpringSource will focus on Groovy performance. This would benefit day-to-day Groovy developers much more than the so called features now being added to the language.

Reply -1 votes
User 207606 avatar

glaforge replied ago:

@devdanke FUD and microbenchmarks again, for what they're worth.
Most benchmarks you can find here and there often show Groovy performing better than all other dynamic languages, even often better than some native scripting languages! But of course, one particular micro-benchmark (like the one you posted, which is outdated anyway) can show Groovy in a less favorable situation.
But I've also seen one micro-benchmark a while ago showing that Groovy was faster than Java at XML handling!
So it really all depends on what your application is doing and is needing.
Groovy apps or web apps are snappy. Groovy's used for intensive apps as well. And see how Grails performs way better than Rails?
Performance of the language itself is important (and we're still working on that anyway), but often, the hot spot in your applications is definitely not the language itself, but poor design, bad database access, lack of UI responsiveness, non optimized algorithms, and more. Rarer are the applications that really need the last millisecond improvement.
People must do their own homework, try the different alternatives, see what the outcome is, before just saying "someone said Groovy is slow for this microbenchmark". There's way more to do to make an educated decision that what you seem to believe.

Reply 1 votes
User 226303 avatar

devdanke replied ago:

@glaforge It's disappointing that you dismiss reasonable criticism and expression of valid frustration with Groovy's problems as "FUD". It's the kind of knee-jerk reaction that reflects poorly on you and the Groovy community.

I'd be grateful if you could list any non micro benchmarks comparing Groovy performance to other JVM languages. I'm not interested in Grails, just Groovy.

In your comment, you stated "[p]erformance of the language itself is important (and we're still working on that anyway)". That sounds nice and you've said it before. But my personal benchmarks of Groovy scripts I wrote for my job and personal projects, and then rewrote in JRuby, still showed Groovy about 10x slower. That's what my "homework" revealed in my effort to make an "educated decision". And the differences were closer to seconds, not milliseconds.

What performance benchmarks does the Groovy dev team use? If I can download those perf tests, I would like to try running them with JRuby and some other dynamic JVM languages. That could be very interesting.

I mainly use Groovy as a command line scripting language, i.e. a replacement for Ruby, Perl, Python, Lua, and Bash. The second area I use Groovy for is unit/functional tests of things like Java web apps & Android apps.

If I were on the Groovy dev team, I'd pay special attention to these types of uses, because they are avenues through which Groovy could most likely enter the enterprise. Groovy does not exist in a vacuum, it's competing against other dynamic JVM languages. If it can't do these things as fast and easily as its competitors, then Groovy's future might not be so bright.

Reply -1 votes
User 207606 avatar

glaforge replied ago:

If you've followed Groovy's history closely, we've continued improving performance across versions, especially runtime performance in Groovy 1.5 and 1.6, and even startup time for 1.7. So this is not something we take lightly.
I confess I had a "knee-jerk reaction" to your comment as it's always annoying to read sentences like "Groovy is by far the slowest dynamic scripting language." This is just plain wrong (even spreading FUD, IMHO), although on some benchmarks we may appear as slower than others, in general, we're often faster in a high number of cases.
On your own personal case, you said Groovy was 10x slower. Slower than what? Than the JRuby equivalent? It'd be interesting to see such a case, and why it's slower. Perhaps there's something wrong in that particular micro-benchmark, or you spotted a real problem in Groovy. And rather than saying boldly that Groovy is slow, please explain in more details what you've been doing, what you were comparing. Otherwise, making such claims doesn't help at all :-(
That said, we still have room for improvements, of course, and we're continuing working on that, especially in Groovy 1.8. So hopefully, you will reconsider your opinion that we "don't address performance", as this has always been one of our concerns.
What else... we're definitely aware of the avenues towards Groovy, that's why our startup speed improvements made sense there, or also see the plethora of testing solutions that emerged in the Groovy ecosystem.
I'd be happy to hear more constructive criticism from yours as to what's lacking in Groovy or its ecosystem, or where you see competitors performing better. Concrete examples of such things will help us a lot more than general comments.
Again, sorry for this "knee jerk" reaction, but however well written your comment was, it was inflamatory to my ears as not concrete examples or justifications were given -- except that old blog post using a very old version of Groovy.

Reply 2 votes

Recommended Links

Written by: Ryan Knight
Featured Refcardz: Top Refcardz:
  1. Apache Hadoop
  2. Play
  3. Akka
  4. Debugging JavaScript
  5. Design Patterns
  1. Apache Hadoop
  2. REST
  3. Java
  4. Git
  5. Java Performance
Connect with DZone