I went to a presentation at my local Java User’s Group last Monday on Guice. I’m a long time Spring user (and fan), so I was interested to see what benefits it had over Spring.

I came away with the impression that Guice looks pretty interesting, but its main benefit over Spring is the lack of XML. That’s okay I guess (although I personally think the case against XML is often overstated). I certainly wouldn’t be opposed to using Guice in a project based on what I saw – except for one thing….

My big issue with Guice is the fact that it appears to be invasive. Based on the presentation I saw it seemed that you need to instrument your code with @Inject annotation for the dependency resolver to provide that dependency. That’s fine in your application code, but it means wrappers seem to be required for third party libraries. However, there are some hints from the documentation that this isn’t the case (‘Observe the Java type and the optional “binding annotation” of the element to be injected‘). OTOH, ‘sometimes you can’t use annotations, and you need to manually wire up an object (a 3rd party component for example). When this comes up, you write a custom provider‘ (See http://code.google.com/p/google-guice/wiki/SpringComparison). That’s kind of confusing, and something I’ll need to investigate more.

All in all – an interesting option, and one that certainly replaces PicoContainer as the best code-centric dependency injection container.