As a follow up to my tests with the Introspector from the Java API, I did some more testing with the following Java Bean to Java Bean mappers:

• Commons BeanUtils
• Spring BeanUtils
• Dozer

Furthermore I used my own implementation and an implementation that’s hardcoded by hand.

The Eclipse project with the sample code for this post can be downloaded as tar.gz or zip or can be viewed online here.

Testing

The performance test creates two beans: one is filled and the other gets filled; this is done over and over again in a big for loop. I coded a by hand implementation as a reference to check whether the process of creating all these new objects is slow. This implementation copies the properties from one bean to the other like so:

bean2.setFoo(bean1.getFoo());
bean2.setBar(bean1.getBar());
bean2.setTee(bean1.getTee());

All the other frameworks had to do the same thing. Have a look at the results (note that I set the y-axis to logarithmic scale):

Obviously there’s no problem with all the created objects: the by hand implementation just consists of the created objects and some method calls to copy the properties. This seems to be pretty fast compared to the other solutions.

Let us have a look at a comparison between the by hand implementation and the frameworks when they have to fill 100k objects:

For example: the by hand implementation beats Dozer by a factor of 970, i.e. it’s 970 times faster.

Conclusion

The results can be explained with the different richness of features. My Introspector and the implementation from the Springframework have very few features and are pretty fast. The Commons BeanUtils implementation has a lot of features (e.g. all this DynaBean stuff). And finally Dozer: I haven’t looked at the code yet, but it seems to be very powerful.

So once more it’s a trade-off between speed and features. Obviously you can’t have both so decide which one your application needs.

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.