Dependency Injection Annotations To Come To A JVM Near You.

Tue, 05 May 2009 18:23:22 GMT

(Via Twitter, where else?)

Remember this (my blog reaction to Google Guice 1.0)? At the time I wondered:

Me:
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?

It's been 779 days since then, but Bob Lee and Rod Johnson have just made public a (work-in-progress) JSR JSR ?: Annotations for Dependency Injection "to standardize a proven, non-controversial set of annotations that make injectable classes portable across frameworks."

Bob Lee: Five years ago, Spring 1.0 brought Java dependency injection into the mainstream. Three years later, Google Guice 1.0 introduced annotation-based dependency injection and made Java programming a little easier. Since then, developers have had to choose between a) writing external configuration or b) importing vendor-specific annotations.

Today, we hope to give developers the best of both worlds. Google Guice and SpringSource have partnered to standardize a proven, non-controversial set of annotations that make injectable classes portable across frameworks. At the moment, the set of specified annotations consists of:

@Inject - Identifies injectable constructors, methods, and fields

@Qualifier - Identifies qualifier annotations

@Scope - Identifies scope annotations

@Named - String-based qualifier

@Singleton - Identifies a type that the injector only instantiates once

One additional interface is specified for use in conjunction with these annotations:

Provider<T> - Provides instances of a type T. For any type T that can be injected, you can also inject Provider<T>.

Scott Bale: What's So Great About Guice

Fri, 09 May 2008 03:49:35 GMT

Scott Bale's presentation about Guice at the St. Louis JUG tonight is well attended and lively.

You can tell Scott liked Guice. He enumerated all the things about Guice that he liked at the beginning of the talk: small, simple powerful, type safe, no xml, easy to use, etc. It's been my experience that people either really like Guice, or they don't care for it at all.

Scott did the brave thing—he did the presentation mostly in Eclipse, with only a few slides. So once again this is one of those "you have to be there to appreciate it" deals.

The presentation is based around a set of simple examples that covers the basic features of Guice. Content-wise, this presentation is similar to what you can find in Google Video. The interesting bits are the conversations with the audience members. Jeff Grigg, Kyle Cordes, Michael Easter, Rob Smith, Dean Farwell, Jeff Cunningham, et. al. were on hand to make the evening a thought provoking and entertaining one.

As for me, I was too tired from moving my daughter back home from school this afternoon and couldn't focus too well on the code on the screen. And I caught the mentioning of Modules, Injectors, Annotations, Scopes, Providers, SINGLETONs, and the binding DSL. Oh, and we did not bash Spring Framework. Honest.

But no worries, the slides and code samples will be posted on the website in a moment.

Google Guice 1.0 Release Sparks Discussions

Mon, 19 Mar 2007 04:18:38 GMT

(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.

Guice lives at Google Code. From there, you'll find the user's guide, Javadocs, and download. Please direct any questions to the mailing list.

The release sparked immediate discussions in the Java blogging community:

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.

"Keep an eye on JSR 299." was the answer.

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!"

Weiqi Gao's Observations - dependency-injection tag

Dependency Injection Annotations To Come To A JVM Near You.

Guice, Or Something Like It, Should Be In The JDK

Scott Bale: What's So Great About Guice

Google Guice 1.0 Release Sparks Discussions

The Nature of Dependency Injection

Embracing Java 5 Features

Guice Is Extremely Easy To Use

Guice, Or Something Like It, Should Be In The JDK

Relation Between DI and Other Patterns

How About That Logo?