Guice: A few thoughts

I’ve just had a quick look at Google Guice (Guice is pronounced like ‘Juice’). It’s a dependency-injection framework, similar to the Spring Framework^[1]. However, it does have some differences. My initial thoughts on this I’ve tried to vaguely collate below. I apologise if I’m not making much sense, it might be better if you have a read through the Guice User’s Guide first!

Pros:

• Guice uses annotations and code rather than an XML file to manage dependencies. So, for example, I can write a method like with the signature: setDependencies(SomeClass dependency1, SomeClass2 dependency2) and just add the @Inject annotation to it. Guice will automatically detect populate the dependencies.
• Guice is apparently a lot faster than the Spring Framework at initialisation. Because Spring has to parse in an XML configuration file, I can well believe this: parsing XML takes a lot more processing power.
• Guice doesn’t index beans by name, it indexes them by class. So, to use an example, in Spring I might use the following code to get a bean:

  DataSource dataSource = (DataSource) applicationContext.getBean("DataSource");

  Whereas in Guice I would use something like the following:

  DataSource dataSource = injector.getInstance(DataSource.class)

  The Guice version is a lot cleaner (it avoids the cast) and less error-prone (using Strings is always liable to mis-spellings and typos)

Cons:

• Guice, at the moment, doesn’t contain a lot of the helper classes. Spring is much more comprehensive – there is absolutely no comparison at the moment. Of course, I don’t think Google want to compete on that level with Spring, and it’s probably not fair to draw that comparison, but I think it’s worth making the point at least. If you go with Guice you may have to use Spring anyway (for e.g. JDBC access, which you can do: Spring is quite modular).
• I think the main reason for me preferring Spring at the moment is that in Guice, the dependency information is mainly stored in application code: you have to implement the ‘Module’ interface, which then loads up the classes and performs all the mapping required etc. The main difference between the two methods is that in Spring, this metadata (telling it which classes need which methods injected) is held in an XML file.

  If I want to configure a DataSource (for example), in Spring it’s fairly easy: you define the DataSource bean and have it load its properties from a properties file (or just specify them in the XML). In Guice, you would have to specify those properties either in application code or write a Provider which loaded up properties. Either way is not ideal.

  I think storing metadata outside of application code is the best way to go for Flexibility – if you want to change the dependencies in a Guice application, you would have to recompile it. This is really not desirable.

  This is why I will be sticking with Spring for the time being!

There probably are a fair few things I haven’t mentioned, but I’ve only looked at Guice for an hour or two – not really in any great depth (as you can tell!). I will definitely be keeping an eye on Guice because I think it’s got a lot of potential – but for now, I think Spring is the framework for me!

^[1] If you have absolutely no idea what I’m talking about, this is all related to Java development… you might want to skip this post now!