Google Guice too self-righteous, stick with Spring

I like Guice, it’s a nice little tool that gets you all excited by doing Dependency Injection using annotations. That’s where it ends though, it really does. Once you’re past the high of using @Inject in a couple of your classes and on to doing something a little more complex, you realize that you’re a little stuck. And by stuck I don’t mean “totally f***ed” I just mean, you’re going to have to jump through some hoops to get it working, one of those hoops might even be refactoring for the sake of using Google Guice and throwing around annotations where you really don’t want annotations, like method parameters. The Guice guys will tell you your code probably sucked anyways and the refactoring is only helping your design – I wouldn’t buy it.

To me object lifecycle management is huge, you know, those methods for your classes which Spring so kindly allows using the InitalizingBean interface or init-method/destroy-method attributes, well that apparently is blasphemy to the Guice folk. Suffice to say they consider it bad practice and horrible design that one of your objects might need some initialization past the actual object creation. Some poor sap had a pretty damn good idea of having @Initialize type annotations for a method you might like to invoke after the object has been created, but he was quickly shot down by the Guice head-honcho who wasn’t convinced that there was a legitimate use-case for this. This effectively kills off anyone who might try to port their application over from Spring – their chief competitor. Instead of lifecycle methods, they want you to implement something called Provider interceptors, yeah, like that’s true DI!

The configuration is a mess, now whoever thinks they’d rather write Java code to configure their DI or IoC stuff instead of XML is beyond f***ed. That’s like saying why use Ant when you can just write one big Java class and do everything inside the main() method. I don’t care how hard they try to make Java code look like English, it still won’t cut it for me. If you prefer having classes in your application that have code like bind(Service.class). to(ServiceImpl.class). in(Scopes.SINGLETON) instead of an XML file, good for you, but I don’t see any benefit whatsoever in adopting this approach. I only see losses: the need for compilation, your configuration spread out in Java classes and difficulty in integrating your “Modules” with other tools.

Guice is also counting on you to create annotations of your own so that you can mark your own source code to help Guice figure out what it needs to do. Prime example is injecting constants, to inject a constant you would need to create a marker annotation, MyConstant and then do a bindConstant().annotatedWith(MyConstant.class).to(123456). Or you could use the @Named annotation which further clutters up your code base to the tune of introducing magic strings. I feel I have to do too much work to get Guice to behave the way I want it to behave, now I’m not lazy and am ready to put forth the effort but it shouldn’t come at the expense of writing custom Providers every time I need to play with a JAR’ed up class.

The good part about Guice is that you can use annotations for DI but the bad part is how messy the configuration classes can become, especially if you’re using third party JARs. The other thing that confuses me is that the Guice team seems to be very concerned about crossing some phantom preset boundaries that would make Guice do “too much” – the lifecycle methods are a prime example. If you’re seriously thinking about challenging Springb shouldn’t you provide a path for people who might actually test the migration? The best you can find is Eric Burke migrating a pea sized application over from Spring which doesn’t say much more than what the Guide says. I also lost faith in the Names class which I hoped would relieve some of the stress of wiring using Java but no such luck since Properties can’t resolve nested keys, but this class is a step in the right direction. They just need something like this, except something that can read in the interface to implementation mappings and other third party classes configuration.

I have a funny feeling that once Spring comes out with annotations for DI, the hype about Guice will die down significantly. Guice would be wise (I think) to actually have a bridge to allow for XML configuration as a supplement for wiring classes (I know it sounds crazy Bob). It would greatly eliminate the need to write Providers which I even feel yucky writing knowing that I’m actually writing code just for configuration sakes. Am I being weird in my thinking that we’re past the point of configuration in unadulterated Java code? I feel whatever is gained with annotations is immediately lost with the woeful configuration technique.


13 thoughts on “Google Guice too self-righteous, stick with Spring

  1. Bob Lee

    Thank you for the feedback.

    Provider interceptors don’t compete with initialization callbacks. Provider interceptors are a more generic idea upon which you could support any type of initialization you like (in addition to custom injection policies, listener registration, decoration, etc.). Rather than focus on one specialized feature, we want to give users a generic tool they can use to build many different features.

    I don’t think Spring vs. Guice is about XML vs. Java. The injection semantics are what’s important. I wouldn’t mind configuring Guice with XML–I might actually prefer it. We even used to have a bug filed for it, but we have too many features which we think we should come first. So many features, so few contributers.

    We’re also not worried about competing with Spring. We open sourced Guice because we wanted to use it in other external projects and so our friends wouldn’t have to repeat the effort, not so we could sell consulting contracts (we aren’t even consultants).

    Finally, writing custom providers does suck. You don’t have to do it too often, but I do still have some ideas for making it a lot easier. Keep an eye out for the next version.

  2. Cedric

    The more I work with Guice, the more I want to use XML configuration for the reasons stated here. I’m using Guice because it’s lightweight and the startup time is very fast compared to Spring. If the Spring distro came with a small JAR which did the DI and nothing more, I’d give it another shot. Why do I need four different Spring jars just to get DI working? It’s overkill.

  3. Kumar Pandey

    That was my exact impression when I looked through the Guice sample.
    Why would a java class configuration would ever be flexible than XML configurations!

  4. Ganeshji Marwaha

    Wow… This is something that i was thinking of writing for quite sometime now, but have been waiting until the initial guice buzz ends…

    I am not against guice, or for spring. In fact, i was one of the people to pounce on this new and shiny DI framework once it came out. Initially, when i had to workaround certain concepts to get things done, i was fine with that, because of the clean DSL guice offers. But going forward, those became pain points, and i had to see guice for what it is… It still is the fastest and the cleanest of all, yet not something that i will ditch spring for.

    BTW, when i tab out of the “url” text box to “say it!” button, the button changes to white color with no text. I experience this on “firefox 2.0”. Just wanted to let u know.

  5. Gandhi

    Google is a company that takes from open source but gives nothing of value back.

    So-called “Guice” is a primary example of where Google could have enhanced Spring, perhaps made something like “Spring Lite”, but decided to make their own incompatible software.

    Then Google heavily promotes their incompatible code, trying to take developer mindshare away from existing solutions that, for most people, work just fine.

    One thing we know about code that Google “contributes” to open source — like all the other Google code that has been “contributed” to open source in the past — it is left to die on the vine.

    Once a person is past the Google hype, there is nothing left but another greedy evil corporation that takes, takes, takes. Sure they hire a few naive dweebs like Bob to put out some Bob Hacks. But nothing of profound value will ever be given back to the community that Google has taken so much from.

  6. Debasish Ghosh

    I think the biggest plus which Guice offers is a lightweight jar and blinding speed. I admit the plethora of Java based configurations, annotations and providers may often prove too invasive in a large project. I have ported one of my small applications to Guice (see my experience in and I enjoyed the DSL approach and the blinding speed which Guice offers. Still for a big project, I would definitely go for Spring.

  7. Pingback: Mika Koivisto ~ Google guice vs Spring

  8. pafinde

    Java v. XML?

    If you wont to define dependencies in XML, you can _really_ easy write a that reads XML and binds classes to interfaces.
    Guice allows you to use XML, but does not forces you to it.

  9. James Royalty


    Thanks for your comments on Guice. I couldn’t agree more — and I’ll be sticking with Spring. Most of us, I’d imagine, use Spring both for DI and flexible configuration. One of my big use cases for Spring is having different config files for multiple deployment targets, filtering and switching between them easily. Moving config (back) into Java code seems like a step backwards to me.

  10. Gili

    I think you are making a fundamental mistake here. Tons of features != good product.

    I am quite glad that the Google Guice authors are thinking their design through and not rushing to provide a migration path from Spring. Google Guice should be as minimalistic as possible but ensure that everything it does it does well. I daresay they’ve done an excellent job from that perspective.

    As others rightfully pointed out: Google Guice lets you use XML configuration files if you wish, but does not force you to do so. Spring is not so kind.

  11. Eelco Hillenius

    I don’t have an opinion about most of your article, but I think the mailing list thread you mentioned is a fine example of a good technical discussion. I think people are right to be very hesitant in adding more features to an API without being absolutely sure it is needed.

  12. kevin king

    Isn’t it game over now that Spring has annotations for dependency injection? I recall seeing some google type giving an intro to dependency injection on the web…as if they had invented the thing… have they never heard of avalon and cocoon? These were stable products before the guy giving the demo was born. Cocoon now uses Spring 2 interestingly

  13. David Sharpe

    Reading this article almost 10 years later it’s hard to not feel wry amusement: “The configuration is a mess, now whoever thinks they’d rather write Java code to configure their DI or IoC stuff instead of XML is beyond f***ed.” Oh yes. XML configuration. Everyone loves XML configuration, right guys? Guys… ?

    (I realize that anyone working in a field long enough will live to see their firmly held opinions ignored and/or invalidated, but it’s still funny to see.)


Leave a Reply

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

You are commenting using your 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 )

Connecting to %s