Grails can be an extremely enjoyable framework to work with. Some days productivity is super-high, code keeps flowing and I find new plugins which fits just like a glove. Grails automatic reloading of changed classes minimizes distractions. And then – bang! – a nasty SQLException with its accompanying 200 line stack trace is dumped on my terminal and brutally interrupts my flow.

The status of the Grails Bug Tracking system October 13, 2009.
During my three months with Grails I’ve stumbled on several confusing bugs in the framework, the majority of which were related to the Grails’ ORM-layer GORM – particularly troubling for me personally as I’ve only limited SQL experience and practically no knowledge of Hibernate (the underpinnings of GORM) at all. Frankly speaking I’d very much prefer it to stay that way, with GORM doing the database heavy lifting behind the scenes and me knowing very little about these mundane tasks. This may be wishful thinking, it certainly is with the current (1.1) version of Grails. I’ve now adopted the routine to always check the Grails JIRA before proceeding with debugging of my own code when I encounter SQLExceptions.
Dean Del Ponte asks if bugs in grails are hurting adoption? The answer is a resounding yes, grails is simply to buggy!
But what does really “too buggy” mean? Its meaning lies of course it the eye of the beholder. Grails is not too buggy to be used in a production setting (if you are willing to accept a fair amount of hacking to get around bugs in the framework and the accompanying loss of developer productivity and morale). Grails is not too buggy for me, its advantages (convention over configuration, brevity, exciting plugins, CRUD scaffolding) far outshines the bugs. Grails is however way too buggy to provide for the smooth learning curve it really deserves.
I finish with some of my pet peeves:
- GRAILS-2735 – Criteria.list() with paginate and sort order causes SQLException
With us since 1.0.2, 13 watchers as of today. - GRAILS-4089 – Default Sort Order for associations causes java.sql.SQLException: Column not found
With us since 1.1-RC1, 16 watchers as of today. - GRAILS-2475 – Criteria Builder causes SQL errors when using pagination and sort
With us since 1.0, 2 watchers as of today.
It’s open source. Submit a patch for them. They will be fixed, everyone will be happy.
What a nonsense, we developed several applications using Grails.
Yes sometimes there is a bug, but there is always a workaround.
Leaving Grails would not weight up against the productivity gain!
Working with Grails without knowing any Hibernate at all might be a little optimistic, but it sure would be nice! I didn’t know at all when I started, but I soon realized that I had to read up on that. It does help, if you know how Hibernate works it’s often easier to understand some of the strangest bugs you run into.
Putting up the number of issues above is misleading. Some of them are enhancements, some bugs. They are also spread across multiple releases, which means that the number of bugs in the particular release you are likely working with is much lower. I’ve been doing some serious work with Grails over the last six months, and while I hit an occasional problem, it really hasn’t been bad at all. I’ve been able to solve or work around all of them so far – that’s part of our trade.
As John mentioned, Grails is open source. The nice thing with open source is that you have a choice – you can do fix bugs yourself, paying with time, or you can hire somebody to fix them for you.
Every framework you might work with, especially one that’s still relatively young and is undergoing rapid evolution, is likely to have bugs.
Grails is a framework acting as a layer on top of Spring / Hibernate / Sitemesh. Yes alot of the time you don’t need to know about Spring / Hibernate / Sitemesh but if you do learn about them then you can do a great deal more in grails than you can without knowing them.
Same with groovy, i’ve been using grails for around a year and only recently started looking at making use of closures, meta programing and other groovy features. Now my grails apps are benefiting from it even though I was getting by without making use of these features before.
You can get by without learning the underlying technologies but then you’ll never take full advantage, the same as anything realy.
Also agree with whats been said, if their is a bug and you don’t like the workarounds you can download the source and submit a patch. (Admittedly I am not at the level to understand the internals enough to do this yet, none the less their is nothing stopping me)
http://blog.peterdelahunty.com/2009/10/grails-iron-man-suit-for-tony-stark.html
Im starting to do some works with Grails. Glad to hear that you guys are always able to solve or workaround the issues.
Had a few years of experience working with java, feel that Grails is a great framework. Thru Grails, i discovered the power of hibernate. Its a shame that i did not try it earlier.
And I am looking forward to the bugs u mentioned. Thanks!
I’ve been working with Grails on a daily basis for almost a year now and had very little Java experience before I started. I really disagree that Grails is to buggy. I’ve finished 3 different Grails projects, all of them in production today and working on my 4th now and haven’t had any big issues.
Essentially if you are a Grails developer with a little ambition your also a Spring/Hibernate/Sitemesh… developer. If you are a Grails developer without ambition you will certainly come a long way without knowing the underlying techniques but don’t expect to take full advantage of the underlying techniques.
If your not willing to understand the techniques which a framework is built upon then maybe you should consider another framework or accept the fact that it might hold you back a little.
Developing with Grails is like walking on eggs.
I found in every new version new bugs. Yes they were fixed often in the next version but the new one introduced new bugs. Yes there were workarounds but all that stuff eats ups most gains in productivity.
Yes, Grails is opensource so everyone can contribute. Yes, Grails is really complex under then hood since its abstracting the complexity of several JEE libraries and frameworks. Yes, there are several work arounds for bugs in Grails. All this is true.
But Grails most certainly is ridden with bugs and each release, some are solved and some are introduced together with new functionality.
There certainly are enough bugs to drop team morale.
Ive seen how development is proceding, specially since SpringSource bought them out. I believe that grails became ready for production since release 1.0.4 and its future is bright but you cant in right mind say these bugs dont affect production.
It is like walking on eggs.
Pingback: Blog harvest, December 2009 « Schneide Blog
to buggy -> too buggy ?
Pingback: Weighing in on programming language investment options for 2010 « Slackhacker
“The search is over”? My work transformed from reliable Java application development to google around trying to workaround Grails bugs. So the search is just beginning…
Grails (and Groovy) are good for small projects.
I’m working on big project which is written in Grails. It has at about 100 domain classes, and tons of services. And programming of such “beast” is PAIN.
Everything is slow! Tests start sloowly (4 minutes to run single integration test and discover that there is … a typo in the code), aplication is slow, coding is mich slower than in java…
IDE does not help the programmer with advanced refactorings (as in Java) or errors detecting (typos, missing classes).
As mentioned by some people – there are bugs in the core of Grails. I lost many days do discover workarounds – even in basic mechanisms such as test runners.
I schould also add a few words about groovy: it’s nice, compact and … too forgiving and liberal. It’s like PHP: it allows programmers to write unmainainable code which has lots of hidden errors.
I will never again use Grails and Groovy in advanced projects as core technologies.