Featured image for “Dependency Injection Options for Java”

Dependency Injection Options for Java

February 17, 2014


Attention: The following article was published over 12 years ago, and the information provided may be aged or outdated. Please keep that in mind as you read the post.

I wanted to take some time to put together a summary of some popular dependency injection (DI) frameworks for Java. This is a high-level overview of what’s available.

First off, what is dependency injection?

“Dependency injection is a software design pattern that allows the removal of hard-coded dependencies and makes it possible to change them, whether at run-time or compile-time.” – Wikipedia

If you’ve ever had a constructor with 12 parameters, you’ve already encountered a compelling reason to use dependency injection.

Most objects require references to other objects to be useful. Dependency injection allows the system to provide those references without you having to manage all of those dependencies at the application level.

This sounds complicated, but it’s really not. Since this is not an in-depth discussion of dependency injection, check out the Wikipedia page for several examples in various languages.

Dagger

Beginning with one of the simplest, most lightweight frameworks available, Dagger is a tiny library (<100KB) that is useful for programs that must minimize their footprint, as in the case of mobile applications. It lacks many of the features of the larger frameworks, but it makes it up in speed and a neat compile-time validation tool.

Google Guice

Guice is Google’s attempt to create a feature-rich, independent DI facility. It is useful in most applications, especially web development. It provides a lot more features than Dagger, but it is slower and can be complex.

Spring DI

Spring is huge. It’ll do everything for you, even write perl so that the perl can then do your laundry. Of course it has dependency injection.

The upside is that if you are already using Spring, enabling and using DI is very easy and makes for a very well integrated approach.

The downside is that if Spring isn’t your thing or you are trying to add DI to an existing enterprise application, it may be challenging to isolate the small subset of features that you want to use.

Spring DI can be configured either through XML or through annotations. I strongly recommend the annotated approach. It is much easier to traverse in code and can provide significant insights to developers that need to understand what’s going on.

Java EE6 CDI

CDI is the Context and Dependency Injection framework that is included in Java Enterprise Edition. On the surface, it looks very similar to Spring’s annotation-based DI mechanism and, in reality, it is. There are some things that it does differently under the covers, but for the most part it is attempting to solve exactly the same problems for the Java EE crowd.

PicoContainer

I mention this one last because I just came across it while poking around the internet. PicoContainer, like Dagger, is a very small framework that intends to do a few things very well. It doesn’t have the features or complexity of Spring or CDI, and in exchange you get simplicity.

I don’t know much about this one but I am now aware of its existence. A new adventure every day!

Deduplication

This post was published with the permission of one of our software consultants, Shannon Griswold (www.thegrisexplores.com). Original text can be found here.

— Shannon Griswold, [email protected]

About The Author

More From Shannon Griswold

About Keyhole Software

Expert team of software developer consultants solving complex software challenges for U.S. clients.

Share This Post

Related Posts


Discuss This Article

Subscribe
Notify of
guest
12 Comments
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
Christian Gruber
Christian Gruber
10 years ago

As a note, Dagger is a Google/Square joint thing. Dagger2 is nearly early access, and is more feature-filled than Dagger 1, 100% compile-time, faster, and has a cleaner configuration model. It lives at http://github.com/google/dagger – the Square folks have given us the go-ahead for the google fork to be canonical for Dagger 2.

Shannon Griswold
Shannon Griswold
10 years ago

That’s excellent news, Christian! Thank you for the update.

I *love* dagger. It has accelerated my development and cleaned up a lot of code.

Robert
Robert
10 years ago

I find Dagger to go in the right direction to eliminate implicit/hidden stuff, but I find it does not go the extra “really no magic” mile. I think that code generation (annotation processing) qualifies as magic in this regard.

If you allow a shameless plug, check out https://github.com/vanillasource/jaywire, which is pure Java 8 Code, less than 20K. If you want explicit dependency wiring, maybe that is what you are looking for.

LG
LG
10 years ago

I created my own injector in a couple of hours. It can inject in static fields, create instances on the fly, it scans the whole classpath for @Component and @Inject, it differentiates singletons and multitons, it can even scan for concrete implementation of abstract components and inject them It also inject loggers with right class type, and much more. It is composed of 4 classes, a bunch of Java 8 , is simple and super fast. I just DONT GET why people use Spring and other shit. People are getting lazier and lazier. everything must use ” industry standard framework BLABLA” .. write your own stuff ! nothing can be more industry standard than that…

Zoli
Zoli
10 years ago
Reply to  LG

Usually people also use other features of Spring.
The other reason is time to market. People already knows Spring and they don’t need to write their own DI and test it. If they need some extra functionality like lifecycle management they don’t need to extend their “framework” and spend time on it. Somebody wants to work on your code? Cool, let’s learn your custom DI for it…
Everybody want to create their own framework…

Robert
Robert
10 years ago
Reply to  Zoli

The other side of that coin is when Time to Market dominates architecture decisions and only short term values are recognized.

Estimating the real cost of making something vs. getting something off-the-shelf is really hard. It is however easy when you only plan short term, which is exactly the reason it is usually only planned short term. But that is a whole other (off-topic) discussion…

In general I agree with LG, that the decision to use something as complicated as Spring, CDI, EJBs or JSF is often not made based on technical merits or even Time to Market, is just a lazy default position.

Injection IS easy, and it shouldn’t require a complex library or runtime. And if a few days of coding can cover the requirements of a particular project, that sounds pretty good to me versus getting a big bundle of third party dependencies.

Adam
Adam
10 years ago

Here is another minimalist DI implementation: https://github.com/AdamSkywalker/ray

cellux
cellux
9 years ago

All the alternatives you listed are very good, with different strong points.

If you don’t mind a shameless plug, if someone is after a more light-weight JSR-330 alternative:
Feather – https://github.com/zsoltherpai/feather

Maybe the smallest there is (16K, no dependencies), and it’s very good in terms of performance (project includes benchmark comparison vs Pico, Guice, Dagger). Works on Android too.

Sayo Oladeji (@oluwasayo_)
Sayo Oladeji (@oluwasayo_)
9 years ago

Coincidentally I’m in the middle of migrating some enterprise apps from Java SE/EE 6 + my own hand-rolled DI framework to Java SE/EE 7 + CDI (Weld). The major reason why people use CDI in this sense is the “C” not the “DI”. Good luck writing your own “C” when you have apps to launch with fast-approaching deadlines.

It’s not laziness at all. My hand-rolled DI framework was so efficient, it uses a hand-rolled annotation processor hooked up to the compiler to index injection targets at compile-time and bound everything all the way down to the DB; clean and simple. It even had impex/trigger features through which changes from the DB propagate back to the application reinject live targets. Guess what? I migrated away from it.

Team mates don’t have to learn my custom DI framework and we now have well-tested battle-haddened “C” in addition to the “DI”.

Gelin Luo
Gelin Luo
9 years ago

okay, it’s a bit late to join. But here is my work inspired by Cellux’s Feather project: https://github.com/osglworks/java-di, it’s yet another JSR330 implementation with bit more feature than Feather and more lightweight in comparing with Guice.

And the di benchmark project is also originated from Feather project: https://github.com/greenlaw110/di-benchmark

Freeman LIU
Freeman LIU
9 years ago

Good job! There is a newcomer tiger, which is the fastest DI framework and easy to use. You probably want to include it.
https://github.com/google/tiger