The war on Grails is really a war on Spring

[Susil]

The war on Grails is really a war on Spring
http://java.dzone.com/news/war-grails-really-war-spring

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.

http://java.dzone.com/news/war-grails-really-war-spring