Is there a simple framework allowing for Dependency Injection in a stand alone program?

Question

We basically need to be able to adjust behaviour at start-up time, by providing desired classes to be produced by various factories inside our application (to avoid the hard binding of the "new" operator).

I am aware that this is provided by several large frameworks, but I was looking for something easily used by a stand-alone Java application without being gigantic.

Any suggestions?

---

Edit: It is my experience that frameworks tend to grow big as part of maturing (and complex too). I need this to be retrofittable to a legacy application as part of major refactoring (technical debt), so simplicity is essential of the used libraries. I do not mind having to do a bit of coding in our application, but it must be very visible what is going on. AOP has a tendency for moving stuff out of the way, and that may make the application harder to maintain.

---

Edit: We have now reached the point where we actually need to make a decision. The application will probably live for decades so we need to make a reversible decision with a framework that will be maintained for hopefully as long. I really like the static type check available with Guice, but not that the annotations bind explicitly to Guice instead of being external like in Spring. I also like that code appears to be more concise when using Guice as opposed to Spring. We need something that is robust and helpful. We do not need more than just DI at the moment. Is there a use case that definitive says go for one of these?

Answer 1

Have you looked at the Google Guice framework? It's pretty lightweight and annotation-based, avoiding XML configuration files

There's also Pico- and Nano-container (from codehaus) which are quite lightweight although the last time I looked (admittedly a few years ago) the documentation was lacking.

I must say that I agree with others about what I assume is your presumption that Spring is massive and confusing. It's really a very simple IoC container and to be recommended.

Answer 2

There are a couple I know of you might find useful:

• PicoContainer
• Plexus (used in Maven)

I've found Plexus very useful in standalone apps as it has optional utility components for CLI interaction.

Answer 3

You can always use Spring Framework 2.5. It is a big one, but if you planning to use only DI you can use spring-core and spring-beans modules, which are pretty small (ca. 500KB and 300KB).

There is also Google Guice 2.0 which comes with a package with only basic stuff (no AOP) and it's 430KB.

Answer 4

By "gigantic" I'm going to assume you're referring to Spring, but that's unfair, since you can cherry-pick the bits of Spring you want to use. If all you need is the IoC container, just use the appropriate JAR files and the appropriate bit of the API, and ignore the rest of it.

Answer 5

Most answers so far seem to be concerned with the size of the jar files to be added.

However I think the more important question is the impact on the project: How many lines of code must be added/changed in order to use the framework?

Even the "big" spring framework is actually very easy to use:

You basically need:

• a xml file that describes your factories.
• one line of code to initialize the container by loading the xml file

The nice thing is that spring is non-intrusive. So you do not have to implement specific interfaces or add any specific annotations or imports to your classes.

At best the single spot where you actually initialize the Spring container is the only place in your application that has an actual dependency to spring classes.

Answer 6

What's wrong with Spring?

These days it's packaged pretty well so you wouldn't need to take the whole kit and caboodle.

As an aside, I'm not a fan of the annotation based injection frameworks. This is because the annotations are bound to the class rather than the instance, the later being a pre-requisite, imho, for DI. This means every instance of a given class gets the same object(s) injected, which seems to defeat the point.

Also consider that DI doesn't even need a framework, what's wrong with your main method wiring together the application?

Answer 7

If you want something maximally simple and appropriate, then write some code that does what you want done. Presumably this involves wiring together factories based partly on fixed logic, and partly on run-time settings.

This has the advantage that the set of possible run-time configurations is known, and so documentable and testable.

It has the disadvantage that an deploying an unanticipated logic change inherently takes an extra second or so of compile time, and (more significantly) can't be sneaked into production without full testing by disguising it as 'just a configuration change'.

Answer 8

I would strongly suggest to take a look at Spring ME. Although originally meant to be a way to use Spring on Java ME applications, it also works fine for standalone applications.

True, it doesn't give you all of the bells and whistles that Spring (Full) has to offer, but then again, Full Spring is much much more than a simple dependency injection framework.

On the plus side: it's based on a (compliant) subset of Spring's configuration files, and the footprint of the runtime is 0%. In fact, there isn't any. Spring ME will take your application context, and turn it into a class that has no dependencies on classes other than your own.

Answer 9

About a year ago I asked myself a question very like this. So I spend a few hours reading the Spring and Guice documentation. After about an hour with Spring I was left feeling that I could get a basic web app going, but had no idea how to use it in a stand alone application. After an hour with the Guice document everything had clicked and I could see just how I to do what I wanted to get done. Now on to recommending Guice? Well no. What does your team already know? If someone already knows say Spring leaver that knowledge and have them spread it about. Like wise with Guice or Pico.

Answer 10

If you want something really light weight you might want to have a look at fuse it's fairly extendable so might be what you're looking for.

cheers

N