Not convinced about Guice, Spring scores again with JavaConfig

March 21, 2007

I’ve been a long time fan of IoC and DI, and have used Spring as my IoC container pretty much exclusively. But I’ve never been a fan of XML-based configuration. So when I first heard about Google Guice I was excited. Over the course of the last couple of weeks I’ve checked out Guice and read a lot of blog posts about it, and in particular about Guice v. Spring. There are a couple of people around saying that Guice is the Spring killer and that Spring has become bloated and closer in nature to that which was despised (i.e. EJB/J2EE). I don’t agree with that sentiment. Guice is no replacement for Spring and does not claim to be. Also, Spring is as lightweight as you want it to be, it is a toolkit and you are free to choose what bits you want from it, or none at all. This debate aside, when I came across Guice I gave it very serious consideration. (There are plenty of tutorials etc. about Guice, so I’m not going to repeat them here.) But it wasn’t long before I found three things I really did not like about it:

  • The need to annotate the classes being managed by the IoC container (@Injection etc.).
  • The difficulty (and I’ll stand corrected if there is a nice/easy way around this) of injecting different implementations for the same interface depending on the context – something which I need to do all the time.
  • The (ridiculous and cumbersome IMHO) need to annotate properties for property injection. Spring is not super fantastic in this regard either, requiring the presence of getters/setters or appropriate constructors, but its still better than the annotation explosion that Guice requires.

So, Spring’s “answer” to Guice is JavaConfig. Wow, the power of competition. Thankyou Google. JavaConfig makes a heck of a lot more sense that XML-based configuration. Craig Walls has an excellent comparison of Spring JavaConfig and Guice. Really, the only point Guice scores against Spring now is speed, and that is not a proper comparison (there is a reason Spring is slower doing injection). More importantly, 99% of the time I don’t see performance in this area being significant when considered in the bigger picture.

I still don’t know enough about Guice to decide definitively where I stand on this one, but for now I’m happily switching to JavaConfig and I’ll continue to watch the space.


11 Responses to “Not convinced about Guice, Spring scores again with JavaConfig”

  1. Kevin B. Says:

    bullet 1:

    V1.1 of Guice will support Provider interceptors, which is a roundabout way of saying that if you want it to inject unannotated methods, there will be away you can make that happen. I don’t think this is a great idea though; I view the requirement of having to explicitly tag the parts of the code that the Injector will be calling as a very good thing.

    bullet 2:

    Whenever I need to do this I just write code that picks the right thing. And that code just has to implement Provider. I haven’t ever thought of this as a burden. If it is, please tell me more!

    bullet 3:

    I don’t think Guice requires an annotation explosion. For example, in our app, we use Guice’s support for binding configuration properties by name. It looks like

    @Inject public MyClass(@Named(“MyPropertyNameHere”) int foo) { … }

    The foo parameter can be any primitive or wrapper type, or Class, or Enum, maybe a few other things I’m forgetting; Guice does the conversion for you. To set it up this way we just have to pass our Properties to a method Guice provides (Names.bindProperties()), or we could also bind individual constants with Binder.bindConstant().annotatedWith(Names.named(“FooBar”)).

    In short, yes, this did require an annotation, @Named, but it’s one we provide.

    Now I’ve gotta send corrections to Craig’s article. 🙂

    Did this help at all?


  2. Kevin B. Says:

    above where it says “the code just has to implement Provider”, what I had really typed was, “Provider<Thing>”. You’ve got an escaping bug in your blog software!

  3. codecurl Says:

    1. So there is a key difference really here in philosophy. I don’t like the idea of having to annotate code to achieve injection, it is invasive, and I’ve then got code that is dependent on a specific IoC/DI framework. And if I was just going to use the Provider workaround all the time, why would I do that? Why not just use Spring JavaConfig?

    2. I need to look at this more, but I think Springs explicit association of an interface with an implementation in the context of a specific instantiation/configuration of a bean is what people generally want and that needs to be a first class citizen. Again, the use of Provider seems like a lot of work when compared with Springs approach.

    3. I stand corrected on the “annotation explosion” comment. However, I see a bunch of other posts around saying the same thing so this is a common misconception. Having said that, see point 1. This is way too intrusive. I’m sure Google is happy to be dependent on Google code – and don’t take this the wrong way, I’m a big Google fan – but I don’t want any more imports and dependencies in my core code that absolutely need to be there. Maximum reuse, maximum flexibility.

  4. Twice Says:

    “This is way too intrusive. I’m sure Google is happy to be dependent on Google code ”

  5. Rod Johnson Says:

    So, Spring’s “answer” to Guice is JavaConfig. Wow, the power of competition.

    Glad you like JavaConfig. But no, it’s not an “answer” to Guice. It predates Guice by quite a while. We just haven’t marketed it much…

  6. […] Not convinced about Guice, Spring scores again with JavaConfig […]

  7. […] Not convinced about Guice, Spring scores again with JavaConfig […]

  8. Gnoletcom Says:

    Please join for discussions on topics about The Virtual Reality.
    Technology development of The Virtual Reality and its perspectives.

  9. mehumaija Says:


    We have a home-grown framework for running Java batches, which mainly targets z/OS-platform (can be run on any platform though). Recently we faced the fact that we really need some kind of DI-framework (to reuse code between J2EE and batch) and were left with three choices; Spring, Guice or build our own. One special requirement was NOT to open too much possibilities to our coders. We want to keep things simple and in full control.

    We took a quick look at Spring and I felt dizzy with the amount of documentation. And this time my surprise wasn’t positive. The amount of packages and classes were huge and we only needed working DI. Bob’s comment on bloated API seems to be real. I decided to dump Spring and enter Guice. It took me just a couple of hours to build full integration between our batch framework (with its own, existing XML-based configuration) and Guice. Wow, that was clearly a sign for me. No changes to configuration and coders just have to use a couple of annotations. I was happy!

    Meanwhile my collegue wrote the same, or similar, tests with Spring, and I got another sign; the code was for some reason “polluted” with Spring classes (things like FileSystemResources or something like that). It doesn’t mean he had to use them, but proved that it (use of Spring just for fun) happens if it’s possible.

    Soon I got surprised again; all my tests ran on z/OS without any problems and were actually a little bit faster (probably due to mandatory switch from JDK 1.4.2 to 5.0). But it worked as expected and ran fast. Remember that zSeries is an EBCDIC machine and too many libraries don’t work there out of the box.

    I didn’t test the Spring code on z/OS, but I’m 99,95% sure it doesn’t work on z/OS as we want (it should ultimately know how to resolve a name like DD:STAXOUT). This is definitely not a statement that Spring doesn’t work on z/OS, but in order to work fully, it means some components should use z/OS-specific APIs like ZFile or ZUtil (provided by IBM JDK). Our framework is using those classes anyhow (when being run on z/OS) in an encapsulated manner.

    So, in conclusion. I’ve seen many comments praising Spring over Guice, but we found Guice a better fit for us. But remember, we just needed DI-framework, not a J2EE replacement.

    Guice rocks!



  10. […] Not convinced about Guice, Spring scores again with JavaConfig […]

  11. jcuw vbzrpqmxt vkyxrbn obuvpij wtybpfl xngcm yjzcxvu

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 )

Google+ photo

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

%d bloggers like this: