Past readers have probably seen some of my posts that include references to the Groovy programming language. At Broadchoice we chose Groovy for the entire server-side object model for our Workspace AIR application. In other words, I've been using Groovy for a while now. And I've been, and continue to be, extremely impressed with it.

If you're a ColdFusion developer, you may want to give Groovy a test drive. Because Groovy is a dynamic language, it plays almost perfectly with CF. You can kiss all those JavaCast() function calls goodbye when your CFML interacts with Groovy objects. Since Groovy runs in the JVM and compiles to bytecode just like CFML (and straight Java for that matter), you can reap its benefits at very little cost in terms of setup.

Further, to those with any familiarity with Java at all, the learning curve with Groovy is really short. Another of the many really cool things about Groovy is that it gives you a very wide spectrum of coding syntax:

On one side, almost any native Java code can be pasted into a Groovy class and it will run fine with no modifications. So any examples, libraries, or legacy code can literally be copied, pasted, and forgotten about, if you want.

But on the other side, Groovy adds a ton of convenience features on top of the core Java language. It takes things that require long, boring, boilerplate Java and incorporates it into the language in a way that just works. And you're free to take advantage of these great time-saving capabilities anywhere you choose to. That's what's so cool: you get to choose! Want or need "normal" Java. Fine. Want tight, terse Groovy? Fine. Want any combination of those? Fine. That's just really damn sweet.

Yesterday, one of the resident mad geniuses of the ColdFusion community, Barney Boisvert, released version 1.0 of his CFGroovy library that makes integrating Groovy (and Hibernate) into CF applications a snap. He also has a very nice post on why you should care about Groovy.

Because it is so seamless to use with CF, so powerful, and so easy to use, I really think we're going to start seeing a lot about Groovy. Add to that the fact that Groovy's object creation speeds, while slower than Java, are far beyond CFCs, and we have a candidate for really robust, large-scale object models while still being able to leverage CF anywhere else in the controller, model, or view that makes sense. So if you like to tinker, learn something new, or do large-scale OO, I'd urge you to check out Groovy and Barney's CFGroovy library.

Comments Comments (10) | del.ico.us del.icio.us | Digg It! Digg It! | Linking Blogs Linking Blogs | 2990 Views

Comments

  • # Posted By Steven Brownlee | 3/25/09 11:29 AM

    Oh yeah, I agree. Even though it's not used at work, I've been picking it up in my (very rare) free time and I'm very impressed so far.

  • # Posted By Allen | 3/25/09 4:00 PM

    Thanks.

    Just curious, and this is probably better suited to a blog post, what are the sort of things you would use CF for instead of Groovy?

  • # Posted By Brian Kotek | 3/25/09 4:18 PM

    Groovy is a language, not a framework and not an application server. So while it adds some great features like dynamic typing, working with collections, String enhancements, closures, and a lot more, it doesn't actually add additional *services*. So for things like mail, Exchange, PDF generation, charting, indexing, etc., CF may be a better choice than trying to find Java libraries to do them. On the same level, there are lots of nice display and UI features that CF offers like AJAX integration, tag-based markup for views, etc.

    So really the best use of Groovy is probably in the model, where its speed and flexibility make it ideal for business logic. It also opens the door to direct integration with things like Spring, Hibernate, JMS, etc. But you can still use CF for the controller and view layers, as well as for parts of the model where you want to leverage some of the great services that CF includes (like Exchange integration, etc.).

    Make sense?

  • # Posted By Jamie Krug | 3/25/09 10:31 PM

    I've been reading the "Programming Groovy" book and it's hard to put down! You summarized the main benefits very nicely and concisely, but there's just some beautiful syntax in there. Groovy manages to shorten Java code, like tenfold on average, while actually making it less complex and easier to read! I can't wait to dive in and do some real coding.

    I have a question out to Barney B already, but I'll throw it out to you as well, in case you have an answer (feel free to contact me directly if it's too long for comment-talk:)... How does the CFGroovy stuff compare/contrast to the CFML/Groovy/Spring/Hibernate stack (like the stuff Alagad did, with tips from Joe Rinehart, like making Spring the parent bean factory of ColdSpring)? I think a huge benefit is having Spring completely take care of your Hibernate transaction stuff, but can you do something similar with CFGroovy too? Pros/cons? Oh, I have so many questions, but I'll stop now and go read some more :)

    Thanks,
    Jamie

  • # Posted By Peter Bell | 3/26/09 1:24 PM

    Well, you might want to check out my new blog at some point! I'm pulling all of my Groovy/Grails onto a different blog which is at http://gettinggroovy.wordpress.com/ so I don't keep bugging CF devs with all the cool stuff I'm finding in Groovy. Expect a post announcing this before the weekend.

  • # Posted By Allen | 3/26/09 1:31 PM

    Thanks for the follow up Brian. It makes sense and helps. Always nice to have a high level picture before diving into the details.

  • # Posted By Thomas Messier | 3/26/09 1:52 PM

    I'm really hoping to see more mentions of CFGroovy and Barney's efforts in the CF blogosphere. I've been rather surprised at how off the radar it's been, relatively speaking. CFGroovy is unbelievably easy to get started with, and while it may have its quirks (and I think some were fixed with the latest version, haven't had a chance to check it out), it can be an extremely useful solution. I hope a lot of people are at least taking it for a spin.

  • # Posted By Sean Corfield | 3/27/09 4:39 PM

    Jamie asks:

    "How does the CFGroovy stuff compare/contrast to the CFML/Groovy/Spring/Hibernate stack (like the stuff Alagad did, with tips from Joe Rinehart, like making Spring the parent bean factory of ColdSpring)?"

    I believe Alagad followed Broadchoice's lead on that stack (while Joe was working for us) but to answer your question:

    CFGroovy lets you mix CFML and Groovy pretty much any way you want. The CFHibernate plugin lets you write Groovy domain objects and use them "directly" inside CFML without much infrastructure.

    By contrast, what we did at Broadchoice was to build an entire Groovy-based model (service layer, domain objects, persistence) entirely with Spring / Hibernate and use BlazeDS for Flex Remoting, all on top of JBoss. Then we reused that model for an HTML app (our iPhone web app) powered by Model-Glue 3 and ColdSpring, powered by Railo - with Spring as the parent context for ColdSpring. So there is a clear delineation between the two worlds.

    Our stack provides a high-performance reusable service-based stack to which CFML can talk but requires quite a bit of work to get it set up - and it "forces" you to write all parts of your model in Groovy. On the other hand, CFGroovy has a lower barrier to entry but is not as "encapsulated".

    To learn Groovy and to experiment with Hibernate, I highly recommend CFGroovy.

    It will be very interesting to see how Joe's "Hoagie" project develops (on which he's working with Alagad I believe) as that will remove the setup "overhead" for the CFML front end / Groovy back end stack that we at Broadchoice have had to deal with.

  • # Posted By Jamie Krug | 3/28/09 11:13 AM

    @Sean,

    Thank you for your very helpful response to my question. Yes, despite finding a lot of information of "the Groovy/Spring/Hibernate/* stack" on the Alagad blog, I figured it was highly inspired/based upon "the Broadchoice stack." So I'll take this opportunity to again thank you, Joe, Brian and everyone else at Broadchoice as well as Doug Hughes for sharing many ideas in a nice format, which will help folks like me get where we want to be with a CFML/Groovy stack much more quickly!

    Initially, I gathered most of the high-level ideas around this stack from the ArgumentCollection blog, Joe Rinehart's blog and finally wrapped my head around how it all fits together when Doug Hughes published this post:
    http://tinyurl.com/c7cebm

    After wrapping my head around the stack Doug documented, I learned a little bit about CFGroovy and was looking for the main capabilities/similarities/differences between what you could do with CFGroovy versus a Broadchoice-style stack. Thanks for your response here and a couple Q&A rounds with Barney Boisvert, I think I've finally got it. As you (and Barney) stated, you can really *mix* CFML and Groovy a good bit when using CFGroovy. This really does seem like a super way for a CF developer to ease into some Groovy!

    Now that Barney has also integrated a CFHibernate plugin with CFGroovy, I realize that you can leverage Groovy for your domain model (along with Hibernate persistence) while keeping CFML powered controller, view and service layers. Since you feel the pain of the CFC creation performance penalty primarily when instantiating large collections of complex domain/business objects, this seems like a nice way to allow Groovy/Hibernate to relieve most of that pain.

    On the other hand, if you go with a full J2EE Broadchoice-style app/stack, you also get to leverage Spring to wire up your Groovy service layer, which comes with the added benefits of easier reuse of your service/model (for different interfaces, as you've done at Broadchoice). It is also my understanding that you'll want to be fully in the J2EE app world to best leverage other enterprise tools like BlazeDS and JMS.

    Finally, after reading the beginning of Doug's post again, it sounds like Joe's Hoagie stack aims to fall somewhere between the CFGroovy app and the all-out J2EE app models. I understand that a Hoagie will take some creative measures to allow for multiple CFML apps (virtual hosts) to run in a single J2EE app *with a Spring container for each*. Doug suggests that this will make it difficult/impossible to leverage tools like BlazeDS and JMS, but it does add the Spring container, allowing a full model (service layer and domain objects) to be used for individual CFML-fronted (view/controller) apps.

    Sorry for the lengthy comment, but I wanted to get it all out for confirmation, and hopefully save some others at my point on the learning curve some research time. Okay, lots of experimenting/learning next :)

    Best,
    Jamie

  • # Posted By Gareth Arch | 6/5/09 5:22 PM

    Hey Brian,
    You mention that the object creation is far better than CF. I have just now run into these issues with a builder I wrote for creating deep nested objects. We have tried using the "trusted cache" feature in CFAdmin to try to alleviate these issues, and, of course, have noticed quite an improvement in speeds. I was just wondering, do you know if I used Groovy whether these speeds would improve over the trusted cache speeds? I figured I'd give CFGroovy a try and see how it compares, but didn't want to dive in too deep (right now when the business needs it done yesterday :) ), if the returns probably wouldn't be there. It sounds interesting enough that I'm sure I'll give it a try anyway, but was just wondering if you might have some input.
    Thanks.