Whenever Google announces something it makes big news. No wonder when Google released its internal Java dependency injection (DI) framework called Guice (pronounced as Juice) to open source, it created a splash in developer community.
Dependency Injection is a pattern to separate an application class from the containers implementation. Another term commonly used for DI is InversionOfControl (IoC). However, IoC is a more generic term with varying interpretation depending upon what control is being inverted. Hence, more precise term being used here is a Dependency Injection. In case of DI, the framework’s container or assembler assumes the responsibility of delivering the required objects or their finder interfaces via constructor or methods. . Such decoupling makes it independent to container. Thus offering a flexible and movable implementation. Moreover, DI based implementations are very good for testing. One may provide mock up implementations and hence test objects which otherwise would be unreachable. A very popular framework Called Spring is a sterling example of such DI / IoC frameworks (http://www.springframework.org). Prior to the rise of DI based frameworks, Service Locator Pattern was commonly used () for locating required components. JNDI lookup is a classic example of this usage pattern.
So Guice is a DI framework. Guice injects constructors, fields and methods. It has some advanced features such as custom scopes, circular dependencies, and static member injection. Is this a path breaking and new disruptive technology? Off-course Not. Currently there already many frameworks like Pico, Nano, Avalon, Gravity, Spice, Jice, Yan and many others and most importantly a very popular Spring! You can find an exhaustive list of IoC based frameworks at http://java-source.net/open-source/containers
Guice developers published a comparison of Guice with Spring at http://code.google.com/p/google-guice/wiki/SpringComparison One of the key difference is how is the dependency defined/bound. Guice is uses Java annotations while Spring has on XML based beans registry.
A side effect of this dependency on Java annotations is you cannot use Guice with JDK versions earlier to JDK1.5 (J2SE 5) because Java Annotation (http://java.sun.com/j2se/1.5.0/docs/guide/language/annotations.html) was introduced in JDk1.5 (J2SE 5).
Annotations are defined in a source code. Thus they introduce a design time dependency. You need to change the code whenever there is a change in configuration. Guice overcome this issue with properties for externalization. You can still add an implementation class in runtime from properties. The key is Guice does not enforce the externalization. So you have a choice.
A comparison paper from Guice Developers about Spring and Guice comments following about configurability and performance. "Spring supports two polar configuration styles: explicit configuration and auto-wiring. Explicit configuration is verbose but maintainable. Auto-wiring is concise but slow and not well suited to non-trivial applications. If you have 100s of developers and 100s of thousands of lines of code, auto-wiring isn't an option. Guice uses annotations to support a best-of-both-worlds approach which is concise but explicit (and maintainable)." We need to read these comment with a grain of salt. Performance impact depends when, where and how many objects being created and passed on. Are “objects being injected” created only during a startup or initializations or in every session? If the objects being created were not high in volume (or created only during startups or initializations) then the performance advantage of Guice would fade away.
Guice provides a faster, simpler and leaner framework for DI. However, Spring has much richer in functionalities in addition to DI. For example Spring XML can do transaction management, aspects, RMI exporting. With much richer functionality, Spring jars are comparatively larger in size than Guice. Guice promoters argue against Spring as it is being “bloated”. But what is a roadmap of Guice? It is always going to be a stripped down DI only framework? Or it will start building Spring like functionalities on top of DI? If Guice too adds more ingredients (read features), it may become equally “bloated”. Guice developers assert that performance is their primary driver. I hope that they maintain this commitment.
So, if you are looking for a DI only functionality. You can give a try to Guice. Google developers say that they are already using it in “mission critical” applications. With Google’s commitment you can have some assurance about a stability and continuity of this framework than many other smaller open source. However, in near future, Spring is still a popular choice for complex application developments. A more educated decision can be based on a feature-to-feature comparison for a type of application that you are building and what additional functionalities that you may need. I thing you know that “taste” is relative. So this Guice may or may not be tasty for all people and every time.
References:
Free Guice from Google
http://code.google.com/p/google-guice/
User Guide
http://docs.google.com/Doc?id=dd2fhx4z_5df5hw8
java Docs
http://google-guice.googlecode.com/svn/trunk/javadoc/index.html
IoC containers
http://java-source.net/open-source/containers
Spring and Guice comparison:
http://code.google.com/p/google-guice/wiki/SpringComparison
Using Spring in Guice: http://google-guice.googlecode.com/svn/trunk/javadoc/com/google/inject/spring/SpringIntegration.html
Service Locator Pattern
http://java.sun.com/blueprints/corej2eepatterns/Patterns/ServiceLocator.html
Dependency Injection using Spring
http://www.springframework.org/docs/reference/beans.html
Guice
Spring
DependencyInjection
IoC
Labels: DI, Guice, IoC, Spring
