Now that the dust has settled a bit from the initial release of Guice, the comparisons with Spring IoC and specifically with Spring JavaConfig are available. Guice and JavaConfig offer different approaches on putting IoC configuration into code using Java annotations.
Spring JavaConfig, which is currently at a 1.0 Milestone 1 release, is based on the sam idea as Guice in that moving away from XML configuration and towards annotations is good in that it puts the knowledge of the configuration closer to the code. Tapestry's IoC container is designed along the same lines.
JavaConfig and Guice come from very similar backgrounds. In fact, Bob Lee has written about their history:
I also have a slightly interesting anecdote: in the very early days, Guice looked very much like Spring's JavaConfig, which isn't surprising considering Rod showed me Spring's JavaConfig almost a year ago (and I showed him Guice about 6 months ago). Just like with JavaConfig, you wrote explicit Java code to wire your objects. I originally introduced @Inject as an optional way to double-check that the external code called all your setters as expected. Once we had @Inject, I asked, why do we need to write explicit wiring code at all? Shortly thereafter, we had the Guice you all know today.
Several posts comment on the differences between Guice and JavaConfig. Debasish Ghosh sums it up nicely when he writes:
The main difference between Guice and Spring lies in the philosophy of how they both look at dependencies and configuration. Spring preaches the non-invasive approach and takes a completely externalized view towards object dependencies. In Spring, you can either wire up dependencies using XML or Spring JavaConfig or Groovy-Spring DSL or some other option like using Spring-annotations. But irrespective of the techniques you use, dependencies are always externalized.
Guice, on the other hand, treats configuration as a first class citizen of your application model and allows them right into your domain model code. Guice modules indicate what to inject, while annotations indicate where to inject. You annotate the class itself with the injections (through @Inject annotation). The drawback (if you consider it to be one) is that you have to import com.google.inject.* within your domain model. But it ensures locality of intentions, explicit semantics of insitu injections through metadata programming.
Through numerous comment threads on these posts you find that the philisophical difference is the biggest thing to be aware of when making a choice between these two frameworks. How close to your code do you want your injections to be? With Guice, your code will be tied to the container, which some people will like an some won't. Guice claims to be faster, however it is noted that Spring's IoC container (whether JavaConfig or otherwise) allows for a full range of hooks that Guice does not. Spring also offers much more than IoC, while Guice does not try to solve such large problems.
