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:

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

9 thoughts on “Grails and legacy code: making old code groovy again!”

Ops, accidentally I deleted a POST from a guy named Bob wich basically said: “this article is a joke right? You are saying here that GORM is a shit?”.

Well, this is a misunderstood. Actually, I think that GORM rocks! It’s an amazing piece of software, and in many ways it leverages Hibernate. I’m not saying here that GORM or Grails sucks. Actually, it’s the exact opposite. Here is shown just one way to reuse your legacy code with Grails.

If your legacy code already uses some other way to access a database, so you’ll not need GORM, that’s the point. The goal here is to reuse ALL your code without having to rewrite it, at all.

For this approach, I need to write my own code (controllers and gsps), instead of grails doing that work for me. Is there any hybrid approach wherein these get generated and I need to tweak in here and there to get it working for my requirement.