Immunizations…er…Injections

I can’t cover all the local events and remain married for long, so I’ve been tossing around ideas that would allow the groups I’m not well tied into to also showcase their work here. Guest blogging is one response to my constraints, and we’re going to try this today. I’ve mentioned Joe Wirtley before. Joe is a fairly well-known independent consultant in our local community. He wrote up Monday’s CINJUG and did a good job conveying the admittedly low-level technical details (read: if you’re not a coder, you might want to move along). He allowed me to re-post his efforts with some very minor editing. Joe, thank you for all your help here.

Andy

At Monday’s Cincinnati Java User Group meeting, Ascendum Solutions consultant, Adam Schaible, gave a presentation on Guice (pronounced ‘juice’) which is Google’s lightweight Java dependency injection framework. So what is dependency injection? Dependency injection allows you to easily separate software components from concrete dependencies; rather than having one class depend directly on another class, you can have that class depend on an interface.

A dependency injection framework provides a way to configure a class to be created for a particular interface. You can then request that the framework create an instance of a class implementing an interface, and it will create the right instance for you. The configuration for a dependency injection framework typically resides in an XML configuration file, but can also be hard coded. You can use dependency injection to support automated unit testing, since you can easily configure a test class to be created rather than a production class. You can also use dependency injection to support a provider model, for example you could have several versions of a component each handling a different database, and select one by configuring a dependency injection framework.

Adam first gave a short introduction to dependency injection, with reference to the classic Martin Fowler example about a mythical MovieFinder class, but quickly moved on to looking at code. Compared to other dependency injection frameworks I’ve seen, the feature that quickly differentiates Guice is that it is configured completely in code and annotations and not in XML. One major advantage of this is that it leverages strong typing, both for compile time checking of class names and for refactoring support. The primary disadvantage is that you must recompile the code to make configuration changes.

The great thing abut Guice is that it makes the easy things easy. For example, it is common to have one default production implementation for an interface. You can express this quite easily in Guice with an annotation on the interface definition:

@ImplementedBy(ServiceImpl.class)
public interface Service {
void go();
}

This code snippet sets the ServiceImpl as the default class to be created when an instance of Service is requested, no other configuration necessary.

Adam described the key components of Guice as:

  • Modules
  • Injectors
  • Providers
  • Automated Bindings
  • Scope

Injectors create objects. Modules provide configuration regarding which classes to create for a given interface; injectors can be created with a list of modules. Providers can be used to customize object creation; the Guice User’s Guide has an example of a custom provider for integrating with JNDI. I don’t remember Adam talking about automated bindings, but I think he may have been referring to the ImplementedBy annotation described above, which creates an automatic binding between the Service interface and ServiceImpl class. Last is scope. By default, Guice creates a new object for every injection. Using scope you can change that behavior. For example, you could use a singleton to ensure the same instance is returned for each injection.

Some other features of Guice include the easy handling of development stages (development, QA, production), the ability to intercept methods, and easily create objects via either eager or lazy loading. Guice is also lightweight; for basic operation it requires a single jar file of approximately 500k.

There was a lot of discussion and questions from the twenty four attendees. Many people were obviously using Spring and there were many questions comparing Spring to Guice or asking how to use Guice with Spring.

Ascendum Solutions provided the pizza for the meeting and announced a networking event to be held February 27 from 6:00-8:00 PM at Buffalo Wild Wings in Glendale. The next Java user group meeting will cover the web framework Wicket.

Joe

Advertisements

~ by Andy on February 19, 2008.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

 
%d bloggers like this: