According to Rod, DI had its beginnings in 2002, in the Interface 21 Framework that was born from his seminal work, Expert One-on-One J2EE Design and Development. In the beginning, DI was done solely through setter injection (SI), with external metadata (usually in XML). 2003 gave us Spring 0.9, which had the same DI model, but added FactoryBeans for indirection and proxy-based AOP (enabling among other things, declarative transaction management). With Spring, DI was always just one enabler of a complete enterprise solution. Contrast that with PicoContainer, also arriving on the scene in 2003, which was an ultra-lightweight DI-only container. PicoContainer brought us several innovations, including constructor injection, automatic resolution by type, and an attempt to dispense with external configuration.

Rod then discussed the Pros and Cons of Constructor Injection (CI). On the Pro side, we see that CI is great for immutable objects, can be used with existing code, enforces that the necessary dependencies are provided at object construction, and allows developers to dispense with methods like afterPropertiesSet(). On the Con side, there are no default arguments in Java, which forces us to ALWAYS provide all of the necessary dependencies, constructor overriding can be somewhat messy, and constructor argument names are not usually available through reflection, which forces us to depend on argument order for dependency resolution.

Spring 1.0, which arrived in late 2003, incorporated some of PicoContainer’s innovation: CI, “Autowiring” by type and by name, as well as the ability to mix CI and SI. Here Rod reflected on Spring’s pragmatic philosophy, whereby they are more than willing to incorporate the good ideas that others had first.

Spring 1.1 brought us method injection, a unique Spring feature, which solved the problem of long-lived managed objects which depend on short-lived objects. It also brought us Factory Methods. You now had the ability to create objects through invoking static factory methods or instance methods on other beans.

With the finalization of the EJB 3.0 standard in May 2006, several new ideas became available in the world of DI: annotation-based DI, annotations for callback methods (e.g. @PostConstruct), scanning for annotations without any external configuration needed for a deployment unit, and field injection (FI). These EJB standard brought with it a new philosophy – that annotations are a superior model and that externalization should be a second-class citizen. The Pros of this standard? One big one – no configuration is necessary for simple cases. The Cons? Rod listed several: resources could only be injected from JNDI, no CI, limited control over object lifecycle, unsuitability for fine-grained object graphs, effectively usable ONLY with annotations, as the XML configuration option is so verbose, and it isn’t just DI – it brings along with it enforcement of many obsolete EJB concepts (such as bean instance pooling).

Spring 2.0 arrived in late 2005 with its own share of innovations: integration with AspectJ, the ability to inject anything with an AspectJ aspect via @Configurable, namespaces to provide an XML-based DSL for external configuration, the @Required annotation, and pluggable scopes to manage the object lifecycle. About that same time, JBoss Seam introduced many strange ideas (that I didn’t quite grasp from Rod’s explanation): bijection, outjection, and subversion of control.

Some additional players on the field include Spring Java Config, which is a DSL for configuration in Java, Google Guice 1.0, and the JSR-299 Web Beans spec, which Rod described as “blogware” in that there is currently no available implementation.

Finally we got to Spring 2.5, released last month. Rod didn’t have his slides printed or available on the web (argh!), so about this time my hand was really hurting from taking furious notes, and I simply gave up. Fortunately, most of what Rod covered was redundant from some of the other sessions, so I’ll have or will blog about it later. About the only thing I really don’t have good notes on is Spring Java Config, which he discussed pretty extensively. If you want to learn more about it, check out http://www.springframework.org/javaconfig.

In the second portion of his talk, Jeremy talked about connecting to Spring. I was really hoping that the “goods” would be delivered here. He started by mentioning DWR, which I think is a really nice framework. It merited 2 slides and no demo (even though there was a slide mentioning a demo). I don’t think Jeremy really cares for it or GWT, as he sort of lumped them together and didn’t mention them again. I do appreciate his point that neither really allows you to harvest any existing controlling infrastructure that we may have built using Spring MVC or another framework.

Jeremy then moved into what he considers the better way to do it, which is the progressive enhancement I mentioned above. He took the existing Spring Booking MVC + Web Flow example application and ajaxified portions of it. He did this using an interesting combination of Apache Tiles, some Javascript “pseudo-AOP” he lifted from the SpringFaces project, and a bit of Dojo. It seemed to work really well, but it wasn’t immediately clear how this type of technology was going to be made available to us as developers. He said something along the lines of “you don’t have to be using JSF to use this Javascript, so we probably need to change the name to something else.” I hope they figure out soon so I can get my hands on it.

He closed by briefly discussing REST’s place in the future of Spring Web. The ideal scenario, according to Jeremy, is that we will be able to request different representations of the same resource. For example, we could request HTML for full page display or partial DOM updates, and JSON for intelligent widgets like the Dojo table.

It looks like a lot of exciting things will happen in 2008. I hope I don’t have to wait too long.

Juergen is the project lead for the Spring Framework, so he was the obvious choice to give this talk. Juergen split it up into three sections:

1. Platforms
2. Annotation Configuration
3. AspectJ Support

To break down part one as quickly as possible, Spring supports virtually EVERYTHING. You get JDK 1.4 all the way to Java 6, including all of the new API’s in Java 6. It fully supports Java EE 5 while remaining backward compatible all the way to J2EE 1.3. You can now deploy a Spring ApplicationContext as a RAR file, and you also get full JCA 1.5 support (if you want to know what that means, don’t ask me ). Quite notable was the fact that they have worked with IBM to support WebSphere’s proprietary transaction manager. Also interesting was Spring’s continuing strong support for OSGi as an alternative enterprise runtime.

The annotation configuration part of the talk was quite fascinating. I’m something of an annotations junkie – I have to be careful about that. At any rate, it was so good that I was interested enough to attend Juergen and Mark Fisher’s later talk that was completely dedicated to the subject. I’ll leave the details for my entry on that talk.

The final portion, on AspectJ support, was equally fascinating. The first new feature was the ability to advise specific beans by name rather than by type using AspectJ. This was made even sweeter by the fact that you can use pattern matching in your definition. Very exciting was the ability to do AspectJ load-time weaving, meaning you can use the power of AspectJ at runtime without involving the AspectJ compiler. Unfortunately, this isn’t available across all appservers. I didn’t get a chance to ask and comfirm, but it seems that JBoss (our primary appserver) does not support this. GlassFish, Weblogic, OC4J, and Tomcat were all mentioned as being able to handle it.

The most interesting part of this talk for me was the ability to annotate a class as @Configurable, and then do dependency injection on it even thought it isn’t managed by Spring. You could do this in Spring 2.0, but you had to use the AspectJ compiler. Now, with load-time weaving, you can do this at runtime! I really could have used this recently when I wanted to inject a single dependency into a class that was really overkill to manage as a Spring bean. Since I’m using Spring 2.5 in this project, I can go back and try this feature. Exciting!