Steven has posted 36 posts at DZone. View Full User Profile

The war on Grails is really a war on Spring

  • submit to reddit

It seems that members of the Rails community have formed a resistance movement against Grails. They won't have it that their web framework doesn't natively run on the best VM in the world. Here's Ted Neward's take on it:

Ruby is perhaps a more flexible language than Groovy (and that's an arguable point, folks, and one which I really don't care to get into), but Ruby also runs on a less-flexible and less-scalable and less-supported platform than Groovy. I dunno that this makes Ruby better. It simply makes it different.

I agree with Ted. Rails and Grails are different and I don't have a grudge against Ruby or Rails. One of the most important differences between Rails and Grails is architecture.

Some people seem to dismiss Grails because it's based on Spring. For them it's so 2003 and a sign of how bloated Grails really is. Yet Spring is at the heart of Grails' architecture, much more so than for example Hibernate. So dismissing Grails because of Spring is a powerful statement.

Spring is at the core of Grails for a good reason. Look at it this way: Grails as a web framework is based on Spring as are many other web applications written in Java. So what's important in Spring to support the architecture of a web application is merely re-used by Grails.

To dismiss Spring is thus in a way to dismiss writing web applications in Java. And some Rails-istas are probably happy to do just that and dismiss Java as a web development platform. Because dismissing Spring is not dismissing the Java language, it's dismissing the Java platform. The fact that Spring and many web applications are written in Java is irrelevant. In the end it's the byte-code and the VM that counts.

Hence, the port of Rails to JRuby comes dangerously close of being rejected by some in the Rails community. After all, the port uses JDBC and the Servlet API (the latter is part of J2EE mind you). Yet I'm sure some Rails-istas are willing to accept this integration with the Java platform, but nothing more.

So, now that Rails-istas are being forced more and more into the Java world - via JRuby - let's look at some of the reasons Grails is based on Spring. But before doing that, let's consider for the moment what Spring does for Java developers.

There is of course dependency injection. But let's ignore that as an argument for now. Spring also integrates with Hibernate and has the best transaction abstraction framework for Java. This framework integrates with more than 10 Java transaction APIs. These last two - Hibernate integration and transaction management - are extremely valuable works of art. Remember that before Spring came along people were writing their own Hibernate integration and transaction management code all the time.

For clarity, here are the most important reasons why Grails is based on Spring, or in other words why Grails needs Spring:

  • Dependency Injection, to configure service objects.
  • Hibernate integration, why re-invent the wheel?
  • Transaction management, to offer transaction management in Grails without any extra work.

Spring also offers the best available JDBC abstraction framework for Java. JRuby on Rails could probably benefit from this, and it would get them free support for transaction management.

Building a complete stack including persistence, transaction management and web framework on top of the JVM without Spring is an expensive thing to do. JRuby on Rails does this and it has to come at an expense. Spring-bashers (Spring is bloated, obsolete, ...) probably don't realize the importance of Spring in the Java world today.

Not only does Spring have the best code quality of all Java open-source projects of this size, it's also well documented. Spring is a collection of highly re-usable components in the domains of persistence, transaction management, dependency injection, remote access, web development and configuration to name the most important ones.

Spring embodies high cohesion, low coupling. It's a dream to build an architecture with Spring because its re-usable components can be used together or alone, are easy to configure and are extremely well designed. Every (web) application that uses persistence and transaction management can benefit from using Spring, as does Grails. There are two notable examples in today's popular full-stack frameworks that have integrated persistence and transaction management and that do not use Spring: Seam and Rails.

Seam doesn't use Spring because JBoss people don't like Spring. Rails doesn't use Spring because it was originally designed to run on the Ruby VM where Spring can't run. Rails-istas that today - now that a Rails port is running on the VM - claim that from an architectural perspective Spring is irrelevant don't know what they're talking about.

And they don't do Rails users a service by revolting against Spring. People are of course free to do that. But just imagine the cost of re-writing Spring. Which is what application server developers are doing as did the Rails development team.

At least in application servers you have the option to use Spring as you please. In Rails you can of course use Spring as well, but it's not integrated in such a way to offer an immediate and concrete benefit to Rails users. Remember that in Grails users have the option to re-use existing Hibernate mappings and Spring configuration files by simply dropping some files. Nobody is required to do this but it's one of the benefits Grails got from Spring.

Nobody can potentially lose from using Spring, there is no such thing. In some circles it's considered a cool thing to say Spring is bloated but there is no evidence to support this. If there is, comments are open below.

My experience in matters of application architecture is that common sense is a winning strategy. As far as I'm concerned Rails is not based on Spring out of common sense: it simply wasn't available when Rails was written. Is it common sense to keep things as they are in Rails?

There is evidence to support that while Spring may offer benefits to Rails it is not required. After all, the port of Rails to JRuby only required integration with the Servlet API and JDBC. This could prove two things:

  • the Rails architecture is very simple
  • Rails has re-written parts of Spring

Rails is somewhat simpler than Grails architecture-wise because there is no object-relational mapping component like Hibernate. But actually there is nothing simple about Rails. It doesn't re-use anything. It's MVC web framework and ActiveRecord have been developed from scratch. This not only comes at a significant cost to develop but also to maintain.

And feature-wise both the MVC framework and ActiveRecord are nothing special. Rails did not become famous because of them (maybe infamous). Rails became famous because it was a disruptive technology. It has rocked quite a few boats. Some years have passed and those boats aren't shaking anymore. In fact, people have consolidated their positions. Grails and many other frameworks are the result of this.

But there's one boat that didn't rock and that the Spring boat. I know quite a few former Spring developers that are now developing with Rails. But that doesn't mean the Spring boat rocked. Ask the SpringSource people, it didn't rock.

Because the Spring creators have understood how architectural problems on the Java platform had to be solved. And everybody benefits. None of this means that Rails should be based on Spring. It does mean that there is no base to dismiss Spring. It's simply too expensive to drop Spring.

Published at DZone with permission of its author, Steven Devijver.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Markus Jais replied on Sun, 2008/02/03 - 5:09am

Personally, I don't care much what's underneath a framework. If it works and gives me the power of Grails (or Rails) the underlying software isn't that important. Grails hides Hibernate, Spring etc. from me. I don't have to be a Spring wizard to use it. I can concentrate on Grails. If they should decide to replace it with something else, I would still use Grails as long as the Grails API stays the same.


Raphael Valyi replied on Sun, 2008/02/03 - 11:31am

"Hence, the port of Rails to JRuby comes dangerously close of being rejected by some in the Rails community. After all, the port uses JDBC and the Servlet API (the latter is part of J2EE mind you). Yet I'm sure some Rails-istas are willing to accept this integration with the Java platform, but nothing more."

-> Hey, wrong point here. JRuby on Rails doesn't have a dependance neither on the JDBC, neither Java servlets.  If you want you can Run with Webrick or Mongrel (with the thin native parser ported to Java). For the data base driver, you can run with the pure Ruby driver while this is not recommended.

So it's just that the JVM offers you a better platform for Rails as well a easy interoperability with the Java stack: you can use it or not, no forced dependence. And even if you use it, it doesn't have any impact on the API's you'll use. That's not like using Spring if you don't want.

Moreover, not all J2EE frameworks are great (far from that actually). But the JDBC and servlet things are arguably the best parts of J2EE and are often considered sane.

BTW, I consider Spring a great framework when you decide to stick away from dynamic languages; so good for the pure java language. Is just that when you go for a dynamic language, being JRuby or Groovy, better solutions exist for injecting dependences, so this is perfectly understandable Grails folks don't want to be forced to using Spring.

Hope this helps. 

Rick Hightower replied on Mon, 2008/02/04 - 1:57am

There is no way Rails can take on Spring. I can prove it! Once and for all!!!!! Adapted from SOA facts (no copyright notice) and for Spring see

  • Spring is the only thing Chuck Norris can't kill.
  • Spring invented the internet, and the internet was invented for Spring.
  • Spring is not complex. You are just dumb.
  • In the last year, Spring increased Turkey's GDP by a factor of 10.
  • One person successfully described Spring completely, and immediately bought a Tomcat support company.
  • Spring is the mistress to all Java Bloggers and CTOs
  • If a tree falls in the forest, Spring knows about it.
  • Spring is being used in the developing world to solve hunger. Entire populations will be fed on future business value.
  • Rod Johnson once died in a terrible accident, but was quickly given Spring. He came back to life, built a multibillion dollar software company, and now buys Tomcat support companies.
  • Spring can write and compile itself.
  • My favorite framework slaughters your favorite framework (please notice the much higher slope for Spring!): spring java, ruby rails Job Trends graph
    spring java, ruby rails Job Trendsspring java jobs - ruby rails jobs
    rick hightowercto of arcMindbloglinkedin

    Stuart Halloway replied on Mon, 2008/02/04 - 10:56am

    You seem to think that Relevance is waging a war on Grails. If so, we are doing a pretty poor job of it. We employ a Grails committer and offer Grails training. We also give all employees Friday to work on open source projects. I guess you would call this our "war on open source." :-)

    Humor aside, I have expanded on my thoughts here. A few quick observations:

    • Hibernate is a good reason for some projects to prefer Grails.
    • Dependency injection is nigh irrelevant in low-ceremony languages. You undermine your credibility touting this as something Rails developers should care about.
    • I share your view that Spring's code and documentation is quite good. But most of the services Spring provides are simply not needed in a low-ceremony language.
    I won't post my bio here, but I hope your readers will decide for themselves who is qualified to have opinions on Java, Spring, Groovy, and Ruby.

    John Wells replied on Mon, 2008/03/17 - 11:01pm in response to: Stuart Halloway

    [quote=stuart.halloway] I won't post my bio here, but I hope your readers will decide for themselves who is qualified to have opinions on Java, Spring, Groovy, and Ruby. [/quote]

     Zing! p0wned...damn....

    Glad to see someone call Mr Hightower out on his constant anti-ruby rhetoric.It really gets old Rick. Really. Why are you so intent on trying to expose Ruby as some sort of imposter?

     Somone take this man's pen. Please.

    Robert Fischer replied on Mon, 2008/12/22 - 9:54am

    Dependency injection is nigh irrelevant in low-ceremony languages. You undermine your credibility touting this as something Rails developers should care about.

    This is an interesting assertion, particularly since I regularly use dependency injection in Grails and miss it in Rails.  I'm wondering if I'm missing something -- why/how do you see this as being the case?

    Comment viewing options

    Select your preferred way to display the comments and click "Save settings" to activate your changes.