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";
(GroovyObject)ScriptBytecodeAdapter.castToType(this, groovy.lang.GroovyObject.class),
"println", new Object[] {
((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.

Tuesday, December 25, 2007

A bit of history. Americans original motivation

I absolutely love history. In fact outside of programming and basketball it has to be my favorite hobby (and yes programming to me is a hobby since I enjoy it so much). For Christmas my wife gave me the Illustrated Edition of "1776" by David McCullough. I enjoyed the original very much and am looking forward to reading it again along with the 140 images and 37 replicated source documents.

Learning new things I think is why I enjoy history so much. For example, in his new book, Author McCullough starts by including an image of what it regarded as our countries first flag: The Grand Union. Also fascinating was the quote by Alison Huber, "Independence from Britain was not as yet what Americans were fighting for, but rather what they felt their rights as freeborn Englishmen." It's real easy to forget something like this and just naturally think our fore fathers started fighting for independence immediately. Instead they were just fighting for the same rights their brothers had back in England.

Stayed tuned as I plan on posting as I read more of the book; or just hit the space bar in Google Reader if you don't care.

Wednesday, December 5, 2007

Google Readers Discover

As if I didn't have enough RSS feeds to read, Google Reader went ahead and recently added a neat little feature called Discover (or Top Recommendations). This new feature provides a short list of new feeds generated by comparing my interests with the feeds of users similar to me. In fact, according to the Help Center, it takes into account my current subscriptions as well as information from my Web History including location. It's actually pretty fascinating and I discovered several interesting feeds that I then subscribed to easily.

If you are already using Google Reader take a look at your list. If not, then consider using or switching to Google Reader; it's discovertastic!