Skip to main content

Java and the need for Dependency Injection

Posted by giovanisalvador on March 16, 2008 at 3:55 PM PDT

I was talking to some of my team mates in Austin regarding the usage of Spring as opposed to "Heavy Weight Containers". They asked what I think about using Spring in the new features of an application they are working on. I have to admit that I never used Spring. Why? Because I never had to. All that I needed to do was supported by EJB Containers or the so called Heavy Weight Containers. Maybe I don't how happy I can be if I use Spring but so far services provived by Java EE containers were enough. And with clustering!!!

I also have to admit that previous versions of EJBs were almost untestable (It's horrible to have to mock an EJB) but at the same time put business logic into EJB (here I am talking about Session and Message-driven EJBs) is something that I don't like that much. I always used POJOs for business logic also to be more testable. My EJBs just acted as a facade to provide remotability. Anyway, when I asked to one of them what was the need he answered me: "I want productivity with Dependency Injection". And more, he told they were going to use Spring integrated with the EJB Container to take advantage of the existing services provided by the container. What? Hum, a self-called lightweight container integrated with a heavyweight container. This sounds interesting. He wanted to have the advantages of dependency injection but also taking advantage of the container's services.

So here I don't take any conclusion despite I have my own opinion on using one or antoher. I just would like to know everybody's opinion on this.

- How are you guys using Spring?

- Has someone already integrated Spring and Java EE container? To take advantage of what?

- And for those who are using only Spring, what are the pros and cons?

- Are you using only the framework or also Spring Portfolio?

I appreciate any comment on it. :)

Related Topics >>


I'd be interested to know what your developer meant by "I want productivity with DI" ... I don't find it makes me any more productive.

What I do like about Spring is how much it cleans up the code. I've been amazed by the number of lines of code I can remove by spring-enabling my objects. The remaining code much more compact and readable after removing all of that uninteresting cruft

I'm with you Giovani. Maybe I'm missing out on the so called goodness of Spring as I'm just a regular J2EE Junky that likes abstracting my business logic in POJOS while using EJBs as the facades to these so that I can get all the unnecessary advantages of the heavyweight J2EE Containers. I think this is going to get worse with EJB 3.x. (i.e. Missing out more on Spring goodness).

Take a look at EJB 3.0. It supports dependency and resource injection, makes testing easy, and has all the advantages of running in a "heavyweight container."

Spring is a wonderful framework that can significantly reduce a programmers workload. However, sometimes you have to have a container. For these occasions I think EJB 3.0 will fit the bill.

Awesome comments. You guys are doing great discussion over here. I like what Eutrilla said about an alternative using Service Locator. Most of my projects started with a Service Locator class :) . Also, as tcowan said, DI was already there in Java. Do you guys remember in EJB 2.x the SessionContext object, being injected using a setter? That was already DI before everybody started to work with DI. And worked, as frydumplng also stated. I don't feel bad because I am not using Spring in my projects. I want solutions to my problems, not create problems for my solutions. That's the bottom line. But I really wanted to see opinion from those who are using Spring, specially integrated with container services. Thanks guys. Keep posting comments. :)

I've been involved in a project that used EJBs (session beans acting as façades for bussiness logic placed in POJOs, sounds familiar?). Anyway, our big architectural problem was the Swing client, which was a mess.

I looked into Spring a bit, but found it too complex (=bloated) for our needs. At the end, we decided to use the Service Locator pattern instead of Dependency Injection. Just a class with a HashMap(Class, Object) and suddenly it was that much easier to access any component of the application by specifying the desired interface.

We put and instance stored inside a singleton and get a one-liner to access any registered service. And now we don't have to write those setXXXInstance() methods if we don't want to, and we don't need a single annotation nor XML file. That much for readability and productivity. Any class that supports Dependency Injection can be plugged in by using a simple wrapper. Definitely not as sexy as Spring or Guice, and has its drawbacks, but it works for us, and can't get much simpler than that.

For us, EJB is not that heavy weight. After all, we only use it as façades. In the clients we register as services either the actual POJOs or a delegate class that encapsulates the EJB lookup in its constuctor. The most annoying thing for me were the extra interfaces required for each EJB, and they're gone in EJB 3. If the Entity Beans dissapeared, I would be quite happy indeed with J2EE and our HashMap.

We're having some fun with the NetBeans Lookup code ( ). It supports the J6 ServiceLocator meme (as introduced in 1.3) out of the box, but the Lookup in and of itself is pluggable as well, so you can have a Lookup implementation for testing and one for production, and run the same code.

Even though we're a EJB shop, we're basically using this so that our code can be EJB independent. So far it's working well, and it's really simple and has effectively no dependencies.

1. Spring emerged from the EJB's failure (complexity and dependency on containers)
2. DI was in use much before Spring (Pico Container)
3. Spring/Hibernate provided that much needed container independence and testability

1. Spring went overboard with the complete stack on DI
2. Anti-patterns emerged when everyone started to use spring for everything. Annotation added fuel to the fire and simple code readability became difficult!
3. The original intent of DI mainly for extensible frameworks got forgotten

What we need is...
1. Everything can not be declarative at the expense of code readability especially in application programming
2. Containers will be required but we perhaps need a much simpler specification that J2EE. EJB3 seems to be the right step but I am skeptical about the vendor implementations....
3. The disproportionate emphasis on tool/IDE driven approach needs to be checked. Yes the average capability of the today's young programmers is way down but dumbing down further is going to hurt in the long run even more...

In short we just need to be careful of not letting J2EE evolve into a monstrous complexity else J2EE is doomed and for the lack of better alternative Spring and the likes might make the things even worse... There will be even more pressure to either move on to scripting languages and ad hoc programming....

I am not against Spring, it's a terrific DI framework, but that's about it. We just need to use that's most appropriate and simple.

I disagree straight away that the choice is between Spring or "heavy weight" containers. Spring ~is~ a heavy weight container. It started well but grew and grew into what is basically an alternative J2EE, jdbc abstractions, MVC, and on and on. Code bases that use it begin to exhibit "spring" in their includes, and there you have have it, raw dependency...your project depends on Spring and cannot get away from it, ever.
You can achive dependency injection without a framework and the JDK has been doing this for years...sometimes with System defines, and other ways, see the XML api and how it allows you to change the underlying implementation. JDBC drivers are another example. I think there is some way of doing this with jar manifests too. If you want a really light weight, clean approach just use Guice ( which unformatately is also being tempted to "work well with X, Y, Z"...but at the moment still seems to be clean, small, and easy to use.

Just to clarify, one of aspects of productivity mentioned, in that case, was the fact of not having to deal with pieces of code for locating resources. For example, looking up JNDI objects without a Service Locator class in place. Just an example.