Are Bugs in Grails Hurting Adoption?
A recent thread on the Grails mailing list sparked an interesting discussion. Some developers have reported that 20%-40% of their development time is spent working around bugs in the Grails framework.
In fact, the thread was less of a discussion and more of an affirmation. I have not personally encountered any showstopper bugs in the Grails framework. My most painful experience has been upgrading older applications from version 1.0.x to 1.1.x. Most of those difficulties were related to plugins and not the framework. Additionally, my applications have been of a smaller nature and not as likely to exercise the Grails codebase like a larger project would.
My personal experience aside, the truth is that many developers are running into bugs that are negatively effecting the gains in productivity which they would expect from Grails.
The Community
The Grails community is a great one as evident from the responses in the mailing list. Here's two quotes which do a good job of summarizing the general feeling of the thread:
- "I look forward to when grails finally becomes more _deeply_ stable - so that I can work in confidence and with peace of mind that this or that functionality isn't going to blow up when I try to actually use it. When it works, it purrs - but man when things fail, they fail hard... train wreck style." - Corey-36
- "I would really much much appriciate if Grails developers would work on fixing all bugs a realease one "really stable" version and just after all these fixing new features could be added." - Daniel Guryca-2
Most respondents agreed that there were definite problems with Grails' stability.
The Response
Okay, so there was some controlled venting, but the nice thing about the community is that shortly after bringing the problems to light, they were addressed.
To help improve stability, submit a JIRA and attach unit tests which expose the defect. This is a very valuable thing any developer can do to help out.
Graeme Rocher has confirmed, via the mailing list, that Grails will start having milestone releases. It would really help if the community tested these builds and submitted JIRAs. Graham also stated that the goal of version 1.2 is stability.
To be fair, one also needs to remember that Grails leverages many underlying technologies (Hibernate, Spring, Groovy, Ant, Maven, etc.). There are strengths to this approach, but there is a small downside. Any bug which exists in an underlying technology inevitably percolates up into the Grails framework and manifests itself as a Grails bug, even if it truly is a bug in Spring or Hibernate.
The Future
The future of Grails continues to look bright, despite a few bumps along the way. Problems with stability and overall 'bugginess' are actively being addressed by the core team of developers and the community. Grails 1.1.x has become more stable and bug free than its predecessor Grails 1.0.x. This trend will continue into Grails 1.2.x and beyond.
What has been your experience with Grails? Are bugs in the framework hurting your productivity or hasn't it been an issue?
Comments:
yes...
by someone on
June 19, 2009
at 7:27 AM CDT
...there are way too many (unexpected) bugs in Grails! It makes development really slow (sometimes). The worst thing though is the really poor documentation - grails is one of the worst documented os projects I know.
Worried about OSGi Adoption
by Forge on
June 19, 2009
at 7:53 AM CDT
I worried about OSGi adoption which will happen with Grails Galahad 2.0 release. How about the restructure?
Also, I really need OSGi adoption.
RE yes...
by Graeme Rocher on
June 19, 2009
at 8:16 AM CDT
@someone I am really curious what you don't like about the documentation we have pretty deep user guide at http://grails.org/doc/1.1.x with references for pretty much everything in the framework.
What makes Grails' documentation bad in your opinion? I don't see that many other open source projects with the amount of material we have in the user guide.
@worried about osgi adoption
Whatever we do with OSGi it will be something we bolt on and won't require drastic restructure. What we're thinking is the ability to have a package-bundle command to create valid OSGi bundles from Grails sources and then also provding support for web slices.
But this is long term and we do want to avoid making drastic changes.
Not as bad as people think
by Sean Tindale on
June 19, 2009
at 8:35 AM CDT
Yes there are Grails bugs. But I really do think that they are being blown out of proportion. I have observed that many Java developers just cant seem to let go and trust something that they haven't explicitly wired up themselves ("not built here" mentality). The average (or even above average) developer is far more likely to introduce bugs than any framework, and to think otherwise is to grossly overstate ones ability. The odd Grails bug is being used as an excuse to revert back to the old "tried and true ways" of "industry standard" development. We need to move forward and stop whining before we fall even further behind other non JVM frameworks (think about the big picture).
Some times
by Kim Betti on
June 19, 2009
at 9:17 AM CDT
Some times it does, but I won't go as fast as saying that 20-40% of my developing time is spent working around Grails bugs.
But when I do encounter a bug though it's often very time consuming to figure it out. Yesterday I was adding a bi-directional relationship between two my application failed to run and gave me a huge not-very-useful stacktrace. When I removed many side, compiled, added the many side again and compiled again it worked. I'm not sure whether it's Grails or Hibernate, but it's very frustrating and hard to reproduce for a proper bug report.
just haven't seen it
by Matt Stine on
June 19, 2009
at 12:34 PM CDT
I have to say that I just haven't seen the level of bugs/issues that others are running into. Thus far my Grails development has been extremely smooth, with occasional problem getting domain model edge cases to work - however I think that has more to do with Hibernate than with Grails specifically. I have yet to have any roughness when doing upgrades, and have carried one project from Grails 1.0.4 through multiple Grails 1.1 betas up to the current release.
@someone - I have to agree with Graeme RE: documentation - Grails is extremely well documented, with perhaps the Spring Framework itself being one of the only projects that I know of that exceeds it in depth.
sadly its really true
by Slava Schmidt on
June 19, 2009
at 4:38 PM CDT
I'm developing a large maven multi-module project right now and one part of them is a grails web site. Its just a small part that is build on top of five other hibernate/spring projects. I'm really spending much as 50 % of my time trying to resolve Grails issues. Especially annoying is to find some _critical_ bugs living in JIRA from 1.0 version. So my decision is to STOP using Grails for future projects at least for one year. After that i'll make new decision about it, but the first thing i'll do is to review the JIRA.
interesting
by jan sokol on
June 19, 2009
at 6:59 PM CDT
I am really surprised hearing about such big amount of critical bugs. For sure there are some bugs but did you really used some framework without bugs? I am using Grails for almost two years and so far didn't find any show stopper bug. Maybe you forgot how big pain is to work in some other frameworks like JSF, Struts....
Regarding documentation, my feeling is that you didn't try to read documentation. I was delighted by Grails documentation from the first day. Even now when I am developing with Grails the http://grails.org/doc/1.1/ page is opened all the time. And when somebody ask me how to start with grails, my advice is first read documentation and then jump to some of the existing books.
Documentation
by Dean Del Ponte on
June 19, 2009
at 9:49 PM CDT
I'd have to agree that the Grails documentation rocks. It's a great reference.
Sakuraba
by saku@raba.jp on
June 21, 2009
at 1:37 PM CDT
I can confirm the following development cycle with Grails:
1) Read about feature x with a trivial sample in the docs
2) Try feature x with real world problem and see it fail
3) Find 1-n bugs in the Grails JIRA that are related to the problem and are blocker and to be fixed some time in the future
4) Spend a half of a day to try to circumvent the hack, reload the entire app over and over again
5) Give up and do things a different/more hacky way
6) Miss the robustness and completeness of Django in Grails
It's true
by Yuriy Zubarev on
June 21, 2009
at 3:19 PM CDT
Yes, it's true. We found a critical for us bug in Grails 1.0, we tried to upgrade to grails 1.1 but it had another critical bug! We tried later on to upgrade to 1.1.1 and it's the same story. It was unreal. We ended up creating more and more work-arounds on the top of Grails 1.0.
I understand that development of Grails is quite complex. It's a framework that sits on top of dozen of other frameworks plus it's using still not very mature Groovy language. I appreciate the complexity Grails developers deal with but at the same time the truth should come out. Grails is buggy if you go beyond "hello world" applications.
sad...
by elik on
June 21, 2009
at 5:10 PM CDT
It is very sad to see all this. I've just started a project using grails 1.1.1. And I indeed got the feeling the whole thing is a bit rough on the edges. I hope it will get better soon...
great discussion
by dlab on
June 21, 2009
at 5:47 PM CDT
I have been using grails during a year and has been very grateful to work with.
I think that the Reference guide is very good, but a certain level you need more, much more. Specially in all the aspects related with Hibernate.
It's true that Grails is a full stack framework and has to deal with problem with the 10 underlying libraries.
When SpringSource bought g2one I thought that they would put more resources (people). IMHO, if they can employ full time developers, Graeme could be able to delegate more, at certain level its impossible for only one person to deal with that much work.
Is not a problem to have a lot of JIRA opened, but when 90% are assigned to one person...
Where can we find 3 or 4 Graeme's more?
Heard of books?
by Reader of books on
June 21, 2009
at 8:38 PM CDT
There are now several good books available for Groovy and Grails, with examples that go beyond "Hello World".
You cant have everything handed to you on a plate. Read!
Most of grails is not writen in groovy
by elik on
June 22, 2009
at 3:23 AM CDT
I didn't dive into the code too much but from what I saw, grails is mostly written in java. Most of the meta programing is done with java and not with groovy. That was one of my greatest surprises when I looked at the grails source code. Not saying it is bad, it is just feels a bit unconsistent.
Grails needs to be Juergenized
by sapporo on
June 22, 2009
at 3:56 AM CDT
We have experienced many productivity-killing Grails bugs as well. And mind you, they were in Grails proper, not Hibernate or Spring.
Personally, I decided to wait for Grails to be Juergenized before I'll base another major project on Grails. That's why I was very happy when SpringSource acquired G2One.
I concur
by Stephen Souness on
June 22, 2009
at 8:05 AM CDT
While working with Grails 1.1 and 1.1.1 I encountered a couple of show-stoppers which caused our project to lose some of the saved we'd saved through convention over configuration.
In 1.1 we were able to save our domain objects, but could not update them - then in Grails 1.1.1 we encountered some corner cases where the GORM functionality had not been wired in for us, so we were unable to save newly created instances of some objects.
While it looks like these issues have now been resolved, I suspect that it may have dented the confidence of the decision makers enough for them to revert back to Java, Spring and Hibernate.
XML processing pain
by Prashanth Gujjeti on
June 22, 2009
at 3:15 PM CDT
I am beginning to adopt Grails as my framework of choice - for pet projects and troubleshooting tools. Just the other day, I came across a very annoying issue: To build a DOM object using the javax.xml.parses.DocumentBuilderFactory, I had to change the grails bundled jaxse.jar file to remove the UserDataHandler.class. Apparently, its a known issue and the class file is included for compatibility with the 1.4 JVM! IMHO, issues like this will make the adaptability of Grails tougher for folks switching to a seamless, agile framework.
what are the bugs?!
by bwtaylor on
June 25, 2009
at 12:52 AM CDT
OK, so everybody is saying "it's buggy" but nobody is saying what the bugs are. Have people that think its buggy filed Jira tickets? Or contribute a unit test demonstrating the bug? Did anybody consider that it's usually easier and better to fix a bug rather than put in a whole bunch of work around code.
not only grails problem
by Peter on
June 25, 2009
at 1:43 AM CDT
Lots of Grails issues is characteristic for whole Java EE. This: "i had to change embeded xxx.1.2.3.2.3.1.4-2.jar to xxx.1.2.3.2.1.1.0-2.jar and then JNDI/Spring/JMX/Hibernate/XXX stopped working" is everywhere. Try to work it out in Boss for example. 5.1 resolves lots of bugs from 5.0 but new Hibernate won't work with MySQL 5.1 because someone commented out two lines of code (from Hibernate) that introtuces "TEXT" type... etc... Of course this won't work with JBoss Tools bur JBoss Tools don't work with new Eclipse either.
Grails is biult from small blocks like other J2EE applications, but You don't need to wire them up on your own, and it makes it easier on top.
Ways build more stability
by Jeremy Flowers on
August 31, 2009
at 2:28 PM CDT
I've been collecting a list of pen source Grails projects. See:
http://twitblogs.com/JGFMK/2009/07/28/grails-links-to-sample-open-source-projects
Maybe a few of these could have tests galore implemented on top of them and this is used as a baseline to make sure future releases don't break. This may be easier said than done as there are sometimes breaking changes in release updates. And as people know Grails is built from so many other moving parts. Sometimes you're contingent on things like fixes to Hibernate event model. I feel the benefits is rapid development far outweigh the debugging costs, which you would more than likely suffer if you were coding with say Spring & Hibernate anyway if the problems were in the underlying frameworks themselves to begin with. So it's a balancing act. Go with the innovations from the underlying stuff and suffer a bit of pain, rather than have a stagnant technology that doesn't keep up with the time.
BUgs and Debugging are hard
by Fabien on
September 23, 2009
at 12:32 PM CDT
I have started a project one month ago and I can say that Grails bugs are really killing my own productivity.
Actually, I got this post by googling "grails too much bugs" because I am fed up with these bugs and I wanted to know if others share my opinion.
Don't get me wrong. I believe that Grails is one of the best available web framework full-stack, but when getting started with Grails, it is hard.
The other BIG inconvenience is the difficulty for debugging, especially when the bug is from the "GRAILS" side.
I am considering moving to Rails or ASP.NET MVC...
Grails in the enterprise
by Fen on
March 24, 2010
at 12:46 PM CDT
In my experience Grails has failed in the enterprise. The stacktrace-less errors and exceptions are a showstopper for me. I've found that there are issues with almost every plugin I've tried. I think that in simple apps and simple db relationships it would be an excellent framework but not for anything serious.
grails stability
by Eric Weimer on
July 23, 2010
at 12:56 PM CDT
I've been working with Grails and Groovy for some time now. The documentation is good relative to other open source projects, but could be better especially regarding Grails internals.
I have lost time to bugs but not more than any non-trivial Java project I've ever worked on. I wonder how many folks with issues are using TDD? With a dynamic language like Groovy, TDD is not only a best practice but (IMHO) ESSENTIAL to success. My most problematic application was one in which my company did not allow TDD (ironically they call themselves an Agile company, lOL). Writing just a few key tests stabilized the code. I took the risk of being "unproductive" for a few days, but it paid off big time.
BUgs are really productivity killers sometimes