Over a million developers have joined DZone.

The war on Grails is really a war on Spring

DZone's Guide to

The war on Grails is really a war on Spring

· Java Zone
Free Resource

Build vs Buy a Data Quality Solution: Which is Best for You? Gain insights on a hybrid approach. Download white paper now!

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.

Build vs Buy a Data Quality Solution: Which is Best for You? Maintaining high quality data is essential for operational efficiency, meaningful analytics and good long-term customer relationships. But, when dealing with multiple sources of data, data quality becomes complex, so you need to know when you should build a custom data quality tools effort over canned solutions. Download our whitepaper for more insights into a hybrid approach.


Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}