Grails is a breath of fresh air for Java developers

Grails creator Graeme Rocher tells us what’s special about the web framework and how it offers developers the best of the Java and the scripting world.

He also talks of how Groovy and Grails complement Java and also when it would be madness to think of using a scripting language over a language like Java.

IndicThreads >> Hi Graeme! Good to have you on IndicThreads. Could you introduce yourself?

Graeme Rocher >> Hi. I’m Graeme Rocher, project lead of Grails and CTO at a company called Skills Matter

IndicThreads >> Could you tell us about the origins of Grails and why you felt the need for such a web framework?

Graeme Rocher >> We started Grails in the summer of 2005. At the time I was doing a lot of content management (CMS) work and had developed several bespoke systems primarily with WebWork & Hibernate. It was productive enough, but it felt clunky so I started writing WebWork actions in Groovy which made a big difference.

“There was a lot I didn’t like about Rails like RHTML (no tag libraries), the way it used inheritance…”

I later tried Rails and really liked it, if I had a choice at the time I might have used it, but unfortunately we had a large number of applications all Spring+Hibernate based. In addition, there was a lot I didn’t like about Rails like RHTML (no tag libraries), the way it used inheritance to provide behaviour, it had no support for atomic conversations (at least at the time, no idea if it does now) spanning several requests and so forth.

“Java still has too much as a platform to give-up on…”

Also, Java still has too much as a platform to give-up on. There are libraries to do just about anything in Java. You have fantastic things happening in the industry like data grid solutions (Terracotta, Coherence etc.), standards-based CMS (JSR-170), and all the innovation within Spring. These are things you simply don’t get elsewhere.

IndicThreads >> Do you look at Groovy as an evolution of Java that’s more suited to Web 2.0 kind of application development?

Graeme Rocher >> No. I look at Groovy as a language to compliment Java development. Dynamic languages are wonderful, but only for simple to medium complex applications, once an application gets complicated having it all in a dynamic language becomes a nightmare.

“Groovy compliments Java. Dynamic languages are wonderful, but only for simple to medium complex applications…”

Groovy allows you to use a blended approach my mixing statically-typed Java for the complex tasks and dynamic Groovy for the easier things without requiring a huge mental shift as you switch from one paradigm to the other.

IndicThreads >> The Ruby On Rails creator had suggested on IndicThreads that “Java should retire from the spotlight of web applications ” . What’s your take on that? Is it time for the scripting languages to take over?

Graeme Rocher >> No I don’t believe so. David is obviously speaking from his experiences in building 37 signals’ applications which are well suited to simplicity and CRUD operations, but the reality is there are many different use cases. Some of which are too complex to be suited to a dynamic language.

“Developing hugely complex applications purely in a dynamic language, whether it is Groovy, Ruby or whatever, would be madness…”

Google have acknowledged this, hence they built GWT to create some of their complex “Office” type applications in Java. I see this also with some of my banking clients who have to deal with hugely complexity with hundreds of clustered machines that need to deal with millions of transactions per second. Developing applications like this purely in a dynamic language, whether it is Groovy, Ruby or whatever, would be madness.

“Grails offers you some of the best features from both worlds …”

The decision as to which web framework you choose is really domain specific. I like to think that Grails offers you some of the best features from both worlds with seamless Java, Spring & Hibernate integration allowing you to scale in terms of complexity as your application grows.
PAGE 1 OF 3
IndicThreads >> Why do you think a Java developer should take the trouble of learning a new language (Groovy) and a new framework like Grails?

Graeme Rocher >> Well, because there is no trouble at all really. Groovy feels very natural to a Java programmer and so to, I believe, does Grails.

“Groovy and Grails feel very natural to a Java programmer…”

From a practical perspective you will see a big productivity boost and massive reduction in LOC (line of code) count as you learn more idiomatic Groovy. At the same time you can continue to leverage your existing Java knowledge and code bases by leveraging services via Spring and also call services written in Groovy from Java.

IndicThreads >> In all probability, you would have heard of Grails being referred to as “just another Rails clone”. Is Grails a Rails clone or is it much more? Do you regret naming it GRails?

Graeme Rocher >> Yes the naming here is unfortunate. It helped us in the early days and I am perfectly happy to admit that using the name benefited Grails in terms of hype.

“The name (Grails) benefited Grails in terms of hype…”

However, Grails definitely has its own unique features such as dynamic tag libraries, a view technology that is not scriptlet based, the ability to use dynamic finders and persistence methods on any Groovy or Java class and its tight integration with Java, Spring & Hibernate.

IndicThreads >> Grails relies on Spring, Hibernate and SiteMesh. Does a developer need some understanding of all these technologies or is some knowledge of Groovy good enough for Grails adoption?

Graeme Rocher >> To begin with, no I don’t believe so. You can develop a Grails application without needing to know anything about any the aforementioned frameworks. However, long term I would say having knowledge of Hibernate and its semantics is crucial to be able to successfully optimise a Grails application.

“You can develop a Grails application without knowing anything about Spring, Hibernate or SiteMesh…”

For example if you don’t understand the difference between join (lazy) and select (eager) fetching you may well run into problems.

IndicThreads >> How do you think should Java developers with say a Struts or EJB background go about adopting Grails?

Graeme Rocher >> Well, most Java people who use Grails (or Rails for that matter) find it a breath of fresh air. Struts & EJB is a very configuration heavy approach, with Grails you can build an entire application and only ever have to configure the data source.

“Most Java people who use Grails (or Rails) find it a breath of fresh air…”

As to the approach you take well that depends very much on the existing codebase. Grails can map onto legacy data sources with Hibernate so that is one approach. You can then just run a Grails application side-by-side with a legacy system as Grails applications are simply WAR files at deployment time.

IndicThreads >> Where do you see Grails going from here? Do you see it replacing popular Java frameworks of today?

Graeme Rocher >> No, I don’t see it replacing all Java frameworks as the framework choice you make is domain specific. If XML publishing is important to you you may choose Cocoon, if your team come from a desktop GUI programming background then maybe a component framework like Seam or Wicket is better suited.

“Grails will provide the solution a lot of Java developers have been looking for…”

I do, however, believe that Grails will become popular and provide the solution a lot of Java developers have been looking for.
PAGE 2 OF 3
IndicThreads >> Often technologies don’t catch on, not because they are lacking but only because they have too many new things. Groovy and Grails also together bring in a lot of new features for the Java developer. Do you think there’s the risk of developers being overwhelmed and hence moving on to something else?

Graeme Rocher >> I think this is the case when the many new things you refer to introduce unnecessary complexity. If a technology is complex you should be questioning why it is so complex. Groovy & Grails are very easy on the surface and allow you to be expressive and creative as a developer.

“Groovy & Grails are very easy on the surface and allow you to be expressive and creative as a developer…”

They don’t, however, take away the underlying power of the JVM and frameworks like Spring & Hibernate.

IndicThreads >> What have you found to be the part that most Java developers struggle with when it comes to adopting Groovy and Grails?

Graeme Rocher >> The Java people don’t tend to find Groovy or Grails too hard. We have a few Ruby people who are “forced” onto the JVM on the mailing list who struggle a bit.

“The main barrier to adoption is management, not the Java developers…”

Jokes aside I think the main barrier to adoption is management, not the Java developers. People naturally resist change and if you have delivered 10 Struts projects why change the status quo?

IndicThreads >> We often see a lot of hype about a technology but little adoption. It just fizzles out and people move on to the next big thing. There’s definitely interest in Grails today, but is it getting adopted? Any Grails success stories you would like to share?

Graeme Rocher >> It most certainly is there are 6 or 7 public facing websites which can be found at http://grails.org/Success+Stories and countless internal projects. I recently heard that someone used Grails in an application that deals with the programmes of satellite offerings in different overseas French islands! So it’s definitely taking off all over.

“Grails is definitely taking off all over…”

IndicThreads >> Thanks Graeme. Also congratulations on the release of your book “Definitive Guide To Grails“.

Graeme Rocher >> Thanks, it was a pleasure answering your questions.

Related
Groovy and Grails Tutorial
Grails web application framework releases new version
Groovy bridges the scripting and the enterprise Java worlds