Friday, December 28, 2007

Justify using Groovy

How does one justify using Groovy on a project? To me it's no different than including any other dependency in my project and in the end it has the same result but with a lot more benefits. There are a lot of skeptics out there, specifically among my team members, and I just can't imagine why they wouldn't want to use Groovy in their every day development. I guess in this instance "knowledge is a curse." It's kind of difficult to explain why I believe in what Groovy is doing, but I will at least give it a try.

First, the biggest initial hurdle people can't get over is they think to start writing Groovy they have to stop writing Java. That couldn't be further from the truth. Groovy was never meant to replace Java. I have used Groovy to write unit tests for my Java code and I have written Groovy code that has used Java code and vic versa. My experience has shown that Groovy and Java just work seamlessly together, especially when using the maven-groovy-plugin and the IntelliJ Idea JetGroovy plugin (for more information see More Groovy Goodies by Joe Kueser).

Secondly, to me the biggest benefit of Groovy, with no cost to the developer, is the hundreds of extra methods added to existing Java classes (see the Groovy JDK). Just by including a new dependency, I have at my disposal hundreds of new time saving methods that I can start using immediately. For example, there are approximately 50 new methods added to java.lang.String (not sure I will ever use all of them but you get the picture). Now lets say for example you were using some open source project like JFreeChart. And you were using version 1.0.8, and 2.0 was out and it included hundreds of new methods. How long would it take you to change the version in your maven2 pom? To me this is not much different than using Groovy to "extend" Java.

Finally, I want to give a quick example of what the end result of a Groovy class is since Groovy is just complied into Java bytecode. Since I have repeatedly stated that Groovy is no different than including a new dependency in your project let me prove it.

Borrowing an example from my previous post, lets say my Groovy class looks something like this:

class GroovyFileTest {
def void test() {
def file = "/workspace/sandbox/grvyfile/src/test.txt"
println new File(file).text()
}
}

My next step would be to use the Groovy Complier (groovyc) to compile my Groovy source into Java bytecode (or just use the maven-groovy-plugin). That would produce GroovyFileTest.class. Using a Java decompiler, such as Jad, here is the outcome:
public void test()
{
Class class1 = GroovyFileTest.class;
Class class2 = groovy.lang.MetaClass.class;
Object file = "/workspace/sandbox/grvyfile/src/test.txt";
ScriptBytecodeAdapter.invokeMethodOnCurrentN(class1,
(GroovyObject)ScriptBytecodeAdapter.castToType(this, groovy.lang.GroovyObject.class),
"println", new Object[] {
ScriptBytecodeAdapter.invokeMethod0(class1,
ScriptBytecodeAdapter.invokeNewN(class1,
java.io.File.class,
((Object) (new Object[] {file}))), "text")});
}

For the sake of clarity I am not including all the other information that was decompiled (well.... because it's rather long). But to summarize, my two line Groovy script is convereted to 214 lines of decompiled Java code. Initially you might think that boosts well for Groovy and really shows the benefits of Groovy, but there is a lot of Groovy going on behind the scenes.

From my perspective this is the only current argument a Groovy skeptic can make: "well look at all that extra junk they are throwing in. Isn't that going to hurt performance?". And at the end it just might. I think it's obvious that Groovy bytecode probably won't run as fast as Java bytecode, but for me the benefits out way that disadvantage.

I by no means intended this to be an exhaustive list of Groovy benefits (for that I would recommend reading the excellent but lengthy article by Guillaume Laforge on the recent Groovy 1.5 features) . I just wanted to prove that the end result is no different. Hopefully people will respond with questions and criticisms and I can respond intelligently.

To me Groovy is sort of the legal steroids of programming. Those that use it have an unfair advantage, enabling them to deliver software quicker then their competitors and co-workers.

8 comments:

Aldrin Leal said...

Your post reminded a silly ad I once saw. I'm rewording to make the point clear:

g   r   o   o   v   y
Justifies Everything

(Ok. Pretend I didn't comment, ok?)

Anonymous said...

After JavaOne '06, I really fell for Groovy and Grails. I sung their praises to just about every developer I knew that I thought was worth telling. I bought e-books and soft copies of Groovy in Action and the Definitive Guide to Grails, just to support the authors.

Eventually, I became slightly less of an evangelist. I had less debates. Less persuasive discourse with folks on my team. I still used the tools, I just talked about them less. But what I realized was that I had started using a pull-model instead of a push-model. I was getting cool things done quickly, and people started asking me how. Soon people were asking me to send them groovy scripts.

That's my experience getting people to see the coolness of it. Just use it and eventually, people will see why it kicks ass and come asking how you did it.

M Easter said...

I like Anon's comment on pull versus push.

Another thought: more than a list of features, Groovy has a slightly different mindset than Java. That mindset is powerful and addictive. Though not often mentioned, it is reminiscent of Python.

The big win, IMHO: Groovy is so approachable and easy to work with that it encourages writing of features/programs that would otherwise be too much drudgery in Java. Though it can certainly be used for full-blown apps (e.g. Grails) it is also great for peripheral features _around_ a core Java app.

To be honest, I find other languages sexier and more interesting. Groovy is just the charming puppy dog that won't go away and keeps winning me over.

Anonymous said...

This is probably a stupid analogy, but it popped into my head, so I'll spew my garbage anyway...

Let's say you take the same road to work every day. It takes you 45 minutes to get to work, it's a little painful, but you get there.

Then they put in a bypass that allows you to get to the same destination in half the time.

Why would you choose not to use the bypass?

I'm hearing similar arguments against using Groovy. "Why would I? There's nothing you can do in Groovy that you can't do in Java!"

Groovy's a bypass that will get you to the same destination as Java in less time. And, oh, by the way, it's also a more scenic drive with less traffic. But, hey, you go right ahead and take the long way. I'll probably be gone when you get here.

jlorenzen said...

The maven-groovy-plugin has been renamed the gmaven plugin. http://docs.codehaus.org/display/GMAVEN/Home

Susan said...

You have worked superbly. I will burrow it and by and by prescribe to my companions. I am sure they will be profited by this site. Wondering where to go in 2019? Things to do has ranked as the best include a remote, idyllic island, the design capital ...

justin said...

Very few details provide on this topic. I get inspired by the writing skills of the writer. I really enjoyed reading this blog. I encourage you to publish more articles with us. Now it's time to get Appointment Setting for more information.

Will Steven said...

Virginia Protective Order is citation issued by the government to the driver who exceed the speed limit