(Neal Gafter started the trend of referring to him as "crazy" Bob Lee.)
After hearing about his DI framework 57 days ago, in the context of my "erase erasure" discussion, I'm very glad to see "crazy" Bob Lee release Google Guice 1.0 as open source:
"crazy" Bob Lee: We're pleased to announce the open source release of Google's internal Java dependency injection framework Guice. Guice wholly embraces annotations and generics, thereby enabling you to wire together and test objects with less effort than ever before. Annotations finally free you from error-prone, refactoring-adverse string identifiers.
Guice injects constructors, fields and methods (any methods with any number of arguments, not just setters). Guice includes advanced features such as custom scopes, circular dependencies, static member injection, Spring integration, and AOP Alliance method interception, most of which you can ignore until you need it.
An earlier version of Guice already powers Struts 2's plugin architecture. Google has been running Guice in mission critical applications for months, and now you can, too. We hope you enjoy Guice as much as we do.
It also sparked several rounds of discussions among colleagues in the office here. I would imagine similar discussions went on in hundreds of other places where Java developers try to solve real world problems.
Here are some aspects of the discussions that I found interesting:
The Nature of Dependency Injection
I've heard all of the following opinions:
DI is just the Strategy pattern.
DI is just the Factory pattern.
DI is a pattern on its own, useful with several other patterns.
I prefer the practice of following the DI pattern without using a third party framework.
I use Spring's DI framework and like the result very much.
Wiring is the term that people use liberally in DI related discussions without too much discrimination. Everybody assumes that everybody else knows what it means, and that its meaning is clear-cut and uniformly agreed.
However, depending on the Who, When, Why, What, How of the wiring, it could be made to mean different things:
internal component assembly (a Swing programmer wiring a custom Model to a GUI component)
component configuration (setting logging appenders and levels for components)
application configuration (selecting to use MySQL vs. Oracle database drivers)
performance tuning (setting the size of the connection pool)
end-user preferences (disabling JavaScript in the browser)
While one can do all of the above using Guice (or some other framework like Spring), it is not always productive to mix all these different kinds of wiring together and treat them as the same thing.
Embracing Java 5 Features
Two and a half years after the release of Java 5, I think it is time for everybody but the most conservative ("my system is done and making me tons of money, I'm not touching it") to move on to the new platform.
I also think it is time for new products and new versions of existing products to exhibit their commitment to the new platform by taking advantage of new language features like annotations and generics.
Those organizations and developers who still operate in the 1.4 platform need to feel all the pressure that associating with a legacy platform engenders.
That's why I'm really glad that Guice is unabashedly embracing annotations and generics and all the rest of the Java 5 language features.
Already, the source code of Guice is the bed for innovative idioms of Java generics, as Neal Gafter pointed out here and here.
Other surprises and a-ha's as I was browsing through Guice source include an implementation of an annotation, the use of String.format(), and the <T> T notNull(T t) template.
Guice Is Extremely Easy To Use
Guice does its job with a straightforward user interface. The User's Guide prints out to about 30 pages of easy to follow recipes. My experience with API design tells me that this is not an accident.
I'm not surprised that Eric was able to swap Guice in to replace Spring IOC in a day.
At this point I must confess that I haven't worked on a so called Spring/Hibernate project that was so prevalent in the last couple of years. And my previous experience with an DI/IOC framework consists of me working out the Pico container tutorial (boy.kiss(girl);, cute) and promptly forgot about the details; and multiple attempts at learning the Spring IOC framework, and feeling like hitting a brick wall when it comes to actually write the @#$%ed xml configuration file.
With Guice there is no XML configuration files, and that's a big win in my book.
Guice, Or Something Like It, Should Be In The JDK
About the only thing that makes feel a little bit uncomfortable is the use of Guice specific imports in my application code.
Wouldn't it be nice if I don't have to do a
import com.google.inject.*;
but do a
import java.lang.inject.*;
instead?
That, and the fear of the dueling frameworks scenario, where I want to use both frameworks A and B while framework A requires Guice 10.7.19 and framework B requires an incompatible Guice 10.8.1, prompt me to suggest that maybe Guice, or something like it, ought to be in the JDK.
So here's my eye on JSR 299—Web Beans. It's scope is Java EE rather than Java SE. But features of Java EE have known to migrate to Java SE.
Relation Between DI and Other Patterns
Although Dependency Injection is officially a design pattern now ("says who?" you ask. "Wikipedia. If it's on Wikipedia, it must be true, right?") in many ways it doesn't feel like a design pattern, although I can't pin down exactly in what way this pattern is not like the others.
Viewed in the narrow sense, DI is a mechanism that links a client that makes use of an interface with a concrete implementation of that interface. Many of the GoF patterns uses the abstract interface/concrete implementation paradigm. Yet I don't think it make sense to say that these patterns depend on (or include) a dependency injection subpattern.
Another clue that dependency injection is different is that it is rarely called dependency injection when done without the assistance of an DI/IOC container—it's just initialization code. It's almost like the situation with garbage collection—when done by hand, it's called memory management.
If you stop to think about it, there is a duality between a dependency injector and a garbage collector: one is where objects come from to live, the other is where objects go to die.
How About That Logo?
If you are familiar with my cute logo theory, you should recognize the genius of announcing Guice with the kid with a glass image. Although not an official logo of the project, the picture is attractive enough that it may very well serve the purpose of a logo.
"The first thing I noticed was the image. It's so cute, I have to try the Guice. I took one sip and am hooked!"
Previous Topic
![""]("http://crazybob.org/uploaded_images/juice-770770.gif")
thereby enabling you to wire together and test objects with less effort than ever before. Annotations finally free you from error-prone, refactoring-adverse string identifiers.