Tag Archives: groovy

The Limits

Erik and I had lunch yesterday with a cool local entrepreneur, Sunny, who has banked his product on Grails. His company also does Grails consulting on the side, so he has several years perspective on using Grails for both his own stuff and for clients.

I was interested in talking with Sunny to discuss the limits of Grails and what had been his experience on things to watch out for. My current Grails project is winding down, and I would like to use it more in the future, so it is always interesting to talk with someone further down the path. Here are some of the nuggets of wisdom he gave us about Grails:

Dynamic Typing

While Sunny appreciates the dynamic nature of Grails, team size can tip it from a benefit to a liability. With more people on the team, he found he was having to write more tests to compensate for an increase in errors from using dynamic typing. Since the compiler can’t pick up all the dumb stuff, a lot of a testing was needed to ensure the correct output. Sunny uses a distributed development team, so not all the developers are sitting in the same room sharing knowledge.

My own guess is that the sweat spot for a Grails team is 3-4 developers working on-site together. As soon as you get too many developers, or they are geographically distributed, the increased productivity of Grails starts to get offset by the extra testing required for simple things that wouldn’t be needed in a statically-typed language. On the plus side, Grails makes it very easy to write tests, but that is still code that needs to be written.

I would imagine this fits in the same sweat spot as Ruby on Rails, so I would be interested to heard from my RoR friends if they see the same issues.

Hibernate

While GORM makes things easy, at it’s roots, it is using Hibernate. That means all the rabbit holes you can go down with Hibernate are just as dangerous in Grails. In Sunny’s case, he has over 100 domain classes in his product, and managing them becomes a chore. The biggest problem is working with deeply nested object hierarchies and cascading updates.

I’ve seen this same issue with straight Hibernate, so it’s not the fault of Grails. One of my prior applications had several eight-to-ten deep persistent object graphs, and it was a total nightmare for doing updates or creating new objects. There was a lot of compensating code around creating the graphs that ended up causing lots of problems when it came time to update an object in the graph. The optimistic locking would get confused and think you were trying to update an outdated version of the master object.

I would apply the same wisdom to Grails as I would to Hibernate: avoid deeply nested domain models.

Performance

I haven’t deployed any Grails applications that handle a high user load, and Sunny’s application is more batch-oriented. What he saw is that Grails got extremely slow in batch operations, mostly due to how Hibernate handled transactions.

He recommended turning on SQL tracing for your hotspots to really see what is going on, and tune appropriately. In his case, he had what he believed was a simple operation, but it resulted in over 20 SQL operations at the Hibernate layer.

This is a danger zone for ORM in general. I’ve seen it on about every Hibernate application I’ve dealt with. Hibernate likes to get chatty, and unless you really pay attention, you can end up with issues that drastically impact your performance under load. If you really care about performance, make sure every SQL operation counts.

Upgrading

I haven’t had to deal with this, but Sunny has worked with applications using about every version of Grails. The big pain is upgrading between Grails versions. Outside the language features that change between versions, plugins are one of the biggest problems. He found that the supported “core” plugins tend to play nicely together in upgrades, but he makes use of a lot of third-party plugins. These plugins end up having version conflicts on transitive dependencies that are painful to sort out.

This is another issue that isn’t specific to Grails, and I’ve run in to on about every large Java project. Java has a rich community, with a billion open source libraries to solve about any need. Unfortunately, you can too easily go into “DLL hell” with your jar files when libraries want to include different versions of the various libraries.

My own preference is to try to stick to the core SDK, be it the JDK, Spring or Grails, and really think hard about what you include. My favorite peeve is including Jakarta Commons just to get a cheap toString() method. You now end up with a frivolous dependency that will end up biting you in the butt later.

Summary

Sunny has been really happy with Grails, in spite of the limitations. He’s looking forward to some of the new Groovy 2.0 features around static typing to eliminate some of the unit testing needs. And it it sounds like Grails is growing. More startups are starting to use it, and it sounds like it is more popular in Europe than here in the states.

Outside the dynamic typing, most the issues he has seen are endemic to any large Java application. Grails still provides a significant productivity boost over any of the other JVM-based options out there.

The Easy Button

I’m about six weeks in to what has turned out to be a medium-sized project, and I’m hating the thought of my next Java project. Why? Because this project is in Grails and it has been such a joy to work with, it will be downright painful to do a classic Java / Spring MVC application again.

This is my third project using Grails. Each project has given me a chance to dig deeper in to the framework. The first project was more as an observer/reviewer and I wasn’t impressed with the outcome. The second project was me writing the code, and it started to click. Now, on the third project, I’m really starting to appreciate the framework.

So why does Grails rock? Here’s a few of the key things I would have a hard time dealing without.

  1. GORM makes database access infinitely simpler than any of the Java alternatives out there. It is simple to create new domain classes, and also to map to existing databases.
  2. Validation is dirt simple. I’m using a few custom flyweight objects for a tricky page, and by adding a simple @Validateable annotation to the class I can make use of a constraints block on my own class. And it ties in with the error messages.
  3. Thanks to the Grails command line, development is super fast. Make changes and they appear immediately. There is no twiddling your fingers waiting on a Maven build script.
  4. The included taglib is actually pretty comprehensive. I still have a fair bit of custom JQuery code, but even it very cleanly ties in to the Grails controllers for AJAX calls.

My only pain with Grails has been the same one that has vexed Java developers for a decade: the java.util.Date class. This class remains a steaming pile, even wrapped in Groovy goodness. But the solution to this problem is one plugin away. Every sane Grails developer should be using the Joda Time plugin to handle dates.

So Grails is my new shizzle. I plan on using it at the next hackathon, and hopefully will use it for my next project. Any Java developer that hasn’t taken a look at Grails 2.0 really needs to give it a glance and see what they’re missing.

Getting Groovy

As we get more into our project at Orange Leap, we’re starting to see a lot of instances where a dynamic language would make our life easier. On all of our entity classes, we associate a map of custom fields. The custom fields are so that clients can customize the entities without us having to change the code each time. The custom field definitions go beyond basic key-value pairs and can include references to other custom fields. For example, spouse is a custom field that relates two entities and is bidirectional. If you open either entity, you’ll see the other in the spouse custom field.

A dynamic language would come into play in that we could access all the attributes of an entity in a consistent way, preferably through dot notation. Since we’re already running on top of Java 6, Groovy came to mind as the best candidate for a dynamic language.

I’ve never really played with Groovy before. I mostly played with Ruby and Rails, which really opened my eyes to the power of a good dynamic language. Some of the developers on my team wanted to get into Groovy while I was at Countrywide, but I kept us out of it for fear of ending up with an unmaintainable monster if one of the experts left. (this is actually the primary motivator in 99% of all enterprise technology decisions — the bus factor)

So this week I finally jumped in with both feet and I have to say I like what I found. Everything cool I liked about Ruby and .NET 3.5 was in Groovy. Metaprogramming, check. Mixins and Closures, check. Full access to all the JVM goodness, check. The recently released Groovy 1.6 even goes beyond Ruby and .NET 3.5.  For example, if you tag a class with the annotation @Singleton, it turns it automagically into a singleton.

@Singleton
class Friend {
    def name
}
f = Friend.instance
f.name = "Tim"
print "Hello, $f.name"

If you try and call new on the Friend class, you get an error that you can’t instantiate a Singleton. All this handled with a simple annotation. For an excellent overview of all the coolness in Groovy 1.6, check out this article on InfoQ.

So I’m going to keep working my way through Programming Groovy and am eager to start applying what I learn. And best of all, my favorite IDE has the industry’s best support for both Groovy and Grails.