Lightweight ioc-Container for Java?

Question

Coming from .NET, I'm used to Ninject, that's a small simple ioc-container. Is there anything simple and lightweight for Java?

The simpler the better!

Solution 1

Pico container or google-guice. See a comparison here.

Btw, few people will call spring "ligthweight", but it can be used as such with only the basic features. Hence it's included in the above comparison.

Solution 2

CDI? (almost the same thing as Guice, but is a JSR rather than proprietary)

Solution 3

Guice?

Solution 4

Silk DI is a 120K jar with no further runtime dependencies needed. So it is way more lightweight than e.g. guice or spring and still smaller as pico-container but has an even more powerful feature set. Also it doesn't cheat by splitting features into a separate additional jars like multibind for guice or the gems for pico-container.

View more solutions

Comments

[brady]

If simplicity is a priority, I second the Pico recommendation. It's called "Pico" for a reason!

[matt b]

I would call Spring lightweight in it's basic usage. It imposes no restrictions or requirements on the classes you use with it, other than being beans-like. All the extra functionality of Spring is there if you need it but not forced on you.

[Bozho]

@matt b - yes, that's why I said it can be used like that. Truth is, it almost never is, because it offers so many extras that you just don't want to revinvent. But the dominant opinion is that is 'heavy' (due to the many extras).

[matt b]

I just wanted to be the one voice voting for in favor of it in this context :)

[rees]

Spring is also heavy in the sense that it is orders of magnitude slower than Pico if you use it to create containers on the fly. In a multi-threaded JUnit test on my Mac, I can create a Pico container, add 4 components to it, and resolve the components around 1,000,000 times in 5 seconds (i.e. create 1,000,000 containers from scratch, etc.). Spring, even using its pure Java API (the XML is just too slow), can still only do about 17,000 in 5 seconds. As well, Spring is many times slower at resolving and creating prototypes. Spring is a fat Swiss Army knife; Pico is a single, sweet DI blade.

[Jonathan S. Fisher]

wow why the heck did this get downvoted?

[MarkWalls]

No idea why someone downvoted you. Not fair, so here is your vote back. :)

[Cristian Rinaldi]

You can use [square.github.io/dagger](Dagger), this is lighter, and so can run on mobile devices. Dagger detects many of the problems at compile time.

[Saifuddin Merchant]

A link might help. Wasn't clear what CDI referred to. Through not sure if anything JEE would fit the definition of lightweight. It won't work outside a container right?

[Jonathan S. Fisher]

Yep. CDI can run completely separate from Java EE. But, these days, Java EE is lightweight compared to the alternatives like Spring. A one-jar build of some of our TomEE based apps is 80mb, runs in 64mb of ram, and cold starts in 10s. Wildfly swarm will give smaller file sizes but starts much slower and has bigger memory runtime requirements (about 2x of TomEE).