Grails and legacy code: making old code groovy again!

Code reuse with Grails is amazingly easy. When working with this framework, it’s really cool to see the huge improvement in productivity that we can achieve. But if you have a large legacy code behind you, this productivity will simply disappear. And this is where Grails really shines and become a real choice for a Java developer.

This week I needed to start a new project which in reality was just a web interface for one of our legacy projects. So, I had some options in front of me: I could start with Struts, JSF or even plain servlets (I was out of my mind to just cogitate this third option!). At  first, I choosed JSF to interact with our legacy code. After all, it was plain Java to deal with Java code, right?

Then I started a new JSF project using Netbeans, added the jars which contained my legacy code + all the other jars which it depends on (basically all the Spring + Hibernate dependencies). Some time after that, I started to face some problems with Tomcat, which was having problems reading my faces configuration file (again). At this moment something hit me: a Grails application doesn’t need domain classes!

In this moment I started my experiment: what if this web interface I needed was entirely wrote in Grails interacting with my legacy code? So I started a new Grails project and used only controllers (just ignored GORM entirely) and my legacy code. And it worked pretty well!

Here is the procedure I took:

1. Start a new Grails project that only uses controller classes

In this state, the only thing I needed to do was to change my DataSource.groovy file to look like the one below:

dataSource {

}
hibernate {

}
// environment specific settings
environments {
development {
dataSource {
}
}
test {
dataSource {
}
}
production {
dataSource {
}
}
}

This step is optional, but is a good move to do so. After all, it’s not a good idea to have a instance of HSQLDB floating around without any use, right?

2. Copy all your jar files to the lib directory of your Grails application

In this case, you only need to copy those jar files which contain your legacy code. And here things get really exciting: as Grails already comes with a full stack, basically you’ll only need to copy your legacy code and few libraries your application relies on.

If your code already uses some of the libraries above, you don’t need to copy their jars to your application. Grails will add them for you: after all, they are the basic components of Grails!. Well, here is the list: Sitemesh, Hibernate, Sprng, Log4J, JUnit, Ant, Commons (several Apache Commons are used by Grails), Xalan, Xerces, Hsqldb.

As you can see, in many cases the only library you’ll need is your JDBC driver. In my case, I only needed to copy the MySQL Connector and JExcel! Neat!

Tip: in your Grails installation directory, browse the contents of the lib folder. Maybe you’ll find some library I just forget to mention.

3. There’s no step 3!!!

At the end of this process, all you have to do consist in work only with controllers classes and it’s respective views. And believe-me: it’s far more productive than using JSF managed beans or actions of Struts!

Notice: in this case, the best thing to do is: forget about GORM!

Main advantages of this approach compared to the use of “traditional” frameworks

• 100% code reuse: did you noticed that in any moment I had to recompile any piece of code? All I needed was my jars! That’s because Grails is based on Groovy which, at the end, generates bytecode. The same bytecode we are used to work with Java!
• Almost zero configuration: did you ever struggled with JSF or Stuts configuration? What about web.xml? Aren’t those files a pain in the ass? In Grails, the only configuration file we had to change was DataSource.groovy!
• It’s Groovy Code: I must admit that I’m tired of working only with Java code. Sometimes is really nice to write in another language. In my case, Groovy is one of the nicests languages I know.
• Easy to deploy: I don’t have to fight agains a huge amount of jar files. I just need to execute grails war and it’s done. All I have to do is send the war file to my server.
• Easy to write (and understand) controllers: just compare a Grails controller to a JSF managed bean or a Struts Action and you’ll know what I mean. It’s not necessary to configure anything. All I need to do is write some closures. That’s nice.
• Filters in a easy way: I’ll not need to implement interface, extend classes or write configuration files. I just need to implement filters the way Grails does. And it works!
• It’s Grails: this is the most important point for me. I’ll have all the productivity gains I expect from Groovy and Grails using my legace code. Your legacy code will feel refreshed!

In the end, I achieved a paradoxal conclusion: if you are just like me, and have tons of legacy code on your back, Grails without GORM is even more powerfull than Grails with GORM. That’s because unfortunately Grails code isn’t easy to reuse. But your legacy code, when wrapped on jar files is!

Another possibility

After finishing this project another possibility of code reuse with Grails showed up: if you have your source code, you don’t even need your jar files. All you have to is to copy your source code to the src folder inside your grails application. It’ll be compiled when you start or deploy your application

(but I still prefer jar files :) )