Comparison between Guice, PicoContainer and Spring

For quite some time it was obligatory to use Spring in a Java project; it became a defacto standard. Once you’re familiar with dependency injection you don’t want to code without it. One alternative to Spring was and still is PicoContainer. But then Guice came along: Googles lightweight dependency injection framework. I investigated it at the time it was released and now I wrote a simple comparison between Guice, PicoContainer and Spring because I’d like to integrate one framework into a project I’m working on.

If you’d like to read and watch something about Guice or Google check out the following links:

• the authors of Guice, Bob Lee and Kevin Bourrillion, present Guice
• Bob Lee presents Guice at the Google Developer Day in Beijing
• Kevin Bourrillion explains to his wife what extraordinarily typesafe means
• watch this short video or check out Googles channel on YouTube to get an impression how they’re working and what they’re working on - quite interesting.

During this comparison I’ll try to focus on DI only. To conclude that, say, Guice or PicoContainer is better than Spring, would be too general to be useful, since Spring is a lot more than just a DI framework.

Setup

I hacked together a simple test that was meant to identify the pros and cons of Guice, PicoContainer and Spring. You can download the Eclipse project as tar.gz or zip or browse the code here; although not needed, you may want to install the Spring plugin for Eclipse. I recommend installing the AspectJ Development Tools, but if you don’t want to install them, make sure to delete the LoggingAspect, the ajbuilder and ajnature from the .project and the ASPECTJRT entry from the .classpath file.

If you start looking at the code check out the ComparisonTest class first, as everything is bootstrapped from there.

All the test does is creating a hierarchy of objects:

• the class SuperManager is the top-level class of the hierarchy
• the three classes OutputManager1, OutputManager2 and ComputationManager are dependencies of SuperManager
• the utility class OutputHelper needs an implementation of Output, i.e. either SystemOutOutput or LoggerOutput.
• one instance of OutputHelper that uses an instance of SystemOutOutput is handed to OutputManager1 and another instance of OutputHelper that uses an instance of LoggerOutput is handed to OutputManager2
• the ComputationManager receives an instance of ComputationHelper and is handed to the instance of SuperManager

Have a look at the dependency graph:

Comparison

Following I’ll list things that I noticed using Guice, PicoContainer and Spring.

Guice

The first thing you’ll notice is that Guice makes extensive use of Java 5 language features, i.e. generics and annotations. While generics lead to the extraordinary type safety mentioned by Kevin Bourrillion, annotations couple your code to the Guice framework. If you’re really picky about loose coupling you might ask why you should use a framework that adds a dependency to itself?! You end up with lots of imports of the Inject annotation scattered all over your code base. And it’s getting worse if you have to use Singleton, ImplementedBy and so on and so forth. You may want to define that elsewhere because your classes shouldn’t know anything about their usage (e.g. Singleton) or where dependencies should be injected (Inject) - that’s what inversion of control is all about, isn’t it?

However, for those who aren’t so picky there are some really cool things about Guice:

• it is type safe
• it reports sane error messages
• it is small and very fast

Well it is really type safe: if you ask Guice to give you an object of type Bar it’ll do so - no cast to Bar required. The authors of Guice don’t want it to be used as a simple service locator for a good reason: your code would still be coupled very tightly. That being said you want to call Guice only in some places in your code where it hands you a top-level class (e.g. a class like SuperManager) where all the dependencies are injected. Whether you’ll have to do a cast on these few occasions shouldn’t be that bad; this puts the big feature of type safety into another perspective (read: isn’t that important). But this is definitely a plus for Guice though.

Reasonable error messages are one point for Guice: if something goes wrong you can identify the problem easily. From a user’s perspective this should be the case anyway but Guice manages this very well - as far as I noticed it.

Finally I’d like to credit Guice for being fast. I haven’t written performance tests myself but Bob Lee wrote a test in March 2007. He came to the conclusion that Guice is more than 50 times faster than Spring. I ran the test lately and got the following results (average of ten test runs):

So it boils down to this:

After that, Guice (1.0) seems to be only 10 times faster than Spring (2.0.6). Have a look at another performance test here.

PicoContainer

PicoContainer is a nice piece of software that facilitates dependency injection without much overhead: no external configuration files (read XML files) and no annotations needed. All you have to do is register your components with the container; for small projects this is an effortless thing.

As with Guice you write everything in Java and can reap the benefits of your IDE’s refactoring capabilities: if you change a class’s name all references will be changed too.

PicoContainer supports the concept of a lifecycle; it isn’t that relevant for my comparison, so if you’re interested you can read about it here.

Spring

Spring is the ultimate dependency injection framework serving the industry for several years. Some years ago every tool had to have an XML configuration; Spring came along with a fancy one and bingo - (almost) everyone liked it. First of all, Spring doesn’t have the aforementioned cool features of Guice or PicoContainer: it is not type safe and doesn’t leverage existing refactoring tools of your IDE (that is Eclipse in my case) - update: the latter isn’t true.

Despite these flaws Spring is well established and seems like a good investment into the future. Opposing to Guice, Spring doesn’t introduce a dependency to itself by default. As long as you don’t use any special features of Spring, your code base will be completely abundant from any dependency injection framework, i.e. if you’d like to go back to dependency injection by hand, you can do so without deleting any annotations or special import statements. You just have to get rid of the XML configuration files.

Spring seems to be harder to use than Guice: without autowiring you have to specify the dependencies between your beans in a very verbose manner, i.e. you have to think about the things you’d like to do and write them down in a configuration file. Ideally you don’t have to specify anything with Guice, except the Inject annotations and Guice will handle everything for you.

Another difference I noticed is that Spring uses singletons by default while Guice doesn’t. If you want a class to be a singleton you’ll have to use the Singleton annotation with Guice. Obviously, both approaches have their strength and weaknesses.

Conclusion

It’s a tough decision to choose one of these frameworks - obviously they’re all pretty cool. First I opted for Guice because I like experimenting with new, bleeding-egde software. But as I mentioned earlier, there might be people on your team who think that all these annotations couple the code to Guice - this takes some evangelizing. Spring, on the other hand, is known for its verbose configuration but also for its robustness and being future-proof.

To draw a conclusion I think choosing between Guice, PicoContainer and Spring, for lack of a hard and fast rule, will be to do what works best for your project. Currently I would recommend using Guice for dependency injection: if you use the annotations wisely they’ll unobtrusively document your code and since you’ll do everything “the Java way”^TM refactoring will be really fun.