Guice and Spring JavaConfig

28 Aug 2007

I’ve been on vacation for the past week or so and took a couple hours to play around with Guice.

Guice != Spring Framework.

For those that don’t know, Guice is a light-weight dependency injection framework. What separates it from a few other frameworks is its reliance on annotations and code-based constructs for wiring together dependencies. There is no XML-based approach to configuration. If you’re one that takes to reading code over xml files, you’ll have no problem adjusting. It took all of a single page of the first tutorial I found for me to get the jist of it and start implementing a simple app.

It’s light-weight in the sense that it does dependency injection and little more. Ensure that the jar is on your classpath and you’re set. If you want web services, advanced AOP, etc. than you’ll most likely be the one having to locate and wire in suitable service implementations.

There’s a good Google Tech Talk that covers Guice in more detail.

Having worked with a couple of Spring projects of various sizes, I can attest to the belief that there is overhead in maintaining configuations in various XML files. However, that’s not to say that a strictly code-based approach would be preferred in all cases, it’s merely an alternative. Having worked with Spring for a couple years now, I’d probably go back and take what I’ve learned and improve existing configurations before considering a more drastic change in configuration strategies. I should mention that Spring JavaConfig does allow you to mix & match code-based and xml-based configurations.

There was a decent post a few months back over on SpringLoaded that did a simple side-by-side comparison of Guice and Spring JavaConfig. JavaConfig is basically an extension to the core Spring framework that allows you to create an annotation-backed ApplicationContext.

Both JavaConfig and Guice do make fairly heavy use of Java5 annotations. Guice is arguably more intrusive as it’s annotations must be inserted into your application code. For example, if you wanted to use setter injection on a class, you would actually add an @Inject annotation on the setXXX() method. Likewise, if you wanted to apply an AOP interceptor to a method, you’d annotate the method and setup the appropriate binding call.

In Guice, you configure an Injector (a quasi-service locator class responsible for providing populated object instances) with an appropriate configuration Module. The Module contains all (or a subset in the event that you’re using multiple Modules) object binding configurations. A binding is essentially a simple mapping of interface to implementation (ie. bind(SomeInterface.class).to(SomeInterfaceImpl.class)) with an optional context.

You also have a central configuration class in JavaConfig but gone is the instrusiveness associated with changing existing application code. The JavaConfig Configuration class implements each required bean as a method (ie. public SomeBean bean1();). It’s up to the implementor of these methods to ensure that appropriate dependencies have been injected. There’s an important trade-off to be aware of here between what’s provided by the framework and what’s expected of the implementation. I must admit that I prefer JavaConfig’s handling of interceptors via a Spring AOP point cut expression to Guice’s annotation.

In the end, I do more or less agree with Craig’s conclusions. There’s some interesting commentary from both Colin (Spring) and Bob Lee (Guice) that is also worth checking out. Given how widespread the use of Spring is, it’ll be interesting to see how the JavaConfig extension plays out (currently it’s 1.0m3).

If I were starting a personal project today, I’d seriously consider using Guice if I needed a dependency injection framework. It’s simple and certaintly fits the bill. Plus, it’s already available in a public maven repository (although JavaConfig is also available via. the Spring Framework’s own repository).

Mmmm new and shiny frameworks!