Grails. It just makes sense.
After a recent Gateway Groovy Users meeting, some of us were talking about the adoption of Grails, which is still on the rise. The signs are everywhere: the increasing number and turnout of Groovy user groups, the number of openings on various job sites, the increasing number of Java frameworks that are including Groovy support.
This led to another question. Why do individuals and companies still say things like “We can't use Grails because we are a Java shop”? Do “Java shops” use Spring? Spring beans can be written in Groovy. Do “Java shops” use JSF? JSF backing beans can be written in Groovy. Contrariwise, most Grails artifacts can be written in Java. Grails is a Java framework, just like Spring, JSF, etc. It just happens to be the first one out with Groovy support – and the best Groovy support, at that.
Consider that Grails uses Groovy for some things for which other Java frameworks use another non-Java language – one that is much further from Java in syntax and usage than Groovy. XML is not Java. XML does not compile to Java byte-code. Grails allows you to use Groovy for many of the things for which other frameworks require (or used to require) you to use XML. Now some other Java frameworks are providing support for Groovy in configuration files, instead of XML. So the differences continue to blur.
More and more developers are seeing the value of Groovy, and consequently tools like Grails and Griffon. You can see this in various polls around the internet, some of which we've discussed in a previous blog post. Now there is hope that more decision makers will get a clue. In a recent article on Forbes.com, Dan Woods makes the case for Groovy in companies that already use Java. The whole article is good, but this line pretty much sums it up: “For a company with a heavy investment in Java, Groovy should be a no-brainer.”
I'm not saying that every Java developer should start using Grails, though that might not be a bad idea. :-) There are some that prefer a component-based framework such as JSF or Wicket to a page based framework like Grails. That's fine: with JSF 2.0 and its Groovy support, JSF is showing some promise.
The bottom line is to use the framework that will help your team be the most productive and do the best job. But we need to get beyond the “we can't use Grails because we are a Java shop” stuff. It just doesn't make sense.
The number one reason for me is that Grails has its own layout convention that is different from Maven's and when you try to build a multi-module project with dependencies on other standalone maven-enabled projects, it just doesn't work.
One thing the Grails community could do to penetrate the Java/enterprise space better, is to reassure that Grails is fast and scalable - a negative reputation on those stuck early.
Even though there are case studies on the likes of BSkyB using at large scale, some consistent and in-depth blogging on real-world, scaled-out and fast sites, with architectures explained, would contribute to eliminating any lingering doubts.
@kpolo - I'm running a multi-module project right now. It looks like this
Basically a parent project with 3 modules. The web module is a grails application.
I'm using the grails maven plugin. It's not perfect but it definitely does work.
I'm working at a Java shop and we introduced Grails this year.
We use a Java Hibernate Domain model, Java service and repository tiers - all written with Spring (that's the core module). The controller and view tier is all Grails (that's the web module).
I would love to see a detailed blog post covering what Neil Thorne commented on.
I think spelling out clearly how people can leverage their existing Java service and repo tiers but using Grails for Web and controller tiers would be hugely beneficial.
@Neil - are you accessing your Hibernate-persisted java pojo's via factories in a Grails service? This is the model I'm using in a project that uses MongoDB rather than a SQL server to persist my pogos.
I'm heartened to see other Java guys with an interest in using Grails and Java together.
I've put an example with more information on the architecture we are currently using here.
It's a bit rushed but hopefully it makes some sense.
I have the same problem Neil Thorne described above. I think Grails is really meant for a non-SOA enviornment. If you can just run a cluster of web server that can directly connect to the database. grails and rails works for you. In the enterprise space, not so much. We are using grails as our rest service api framework. grails just add too much unnecessary library in the war. we have to increase our permgen to build! grails maven is also a pain to use, application.properties need to be updated to reflect the version in the pom. I just rewrote all of our grails project to CXF. It became much more light weight. The only reason I will use grails for is to build admin tools for our services. However, spring mvc is already easy enough to use and our code can be modulize into smaller component and re-use in different services. Modulizing our project will also make us easy to move to osgi.
The Groovy and Grails communities are missing a chance to evangelize to non-Java developers. Grails is great in its own right, not solely because it's "better Java".
The Grails books, especially, always make a point of comparing Grails to other Java web platforms, and point out how little boilerplate is needed to get the job done. While that's nice, it doesn't impress those of us who have always avoided Java web stuff precisely because of all the 'high ceremony' typically associated with Java web projects.
Compare Grails to Rails, Django, Symfony, CakePHP and other non-JVM platforms. There will be some areas where Grails comes up short, certainly, but there will also be some wins. There are people moving from non-JVM platforms in to the JVM precisely because of Grails, but there's precious little out there that speaks to them in helping make a transition.
I'd bet there's far more web developers building in PHP, Ruby, Python and .Net than there are in Java, yet nearly all of the Grails messaging is only targeting existing Java developers. Switching someone from using Seam to Grails might grow the Grails community, but doesn't grow the JVM pie, as it were.
Post a Comment