To Authors: Dependency Injection Spring v/s others

In the Dependency Injection space, there are a lot of players alongside Spring - Pico, Hivemind etc.

Is Spring superior than the rest
(I am no into flame war. I honestly would like to know)

Thanks,
Srikanth

Think I found the answer here https://coderanch.com/t/59842/oa/Spring-vs-HiveMind
and elsewhere.

I think Almost all of them are same wrt Dependency Injection

Originally posted by Srikanth Shenoy:
In the Dependency Injection space, there are a lot of players alongside Spring - Pico, Hivemind etc.

Is Spring superior than the rest
(I am no into flame war. I honestly would like to know)

Thanks,
Srikanth

In the DI space, there are four main players--Spring, Hivemind, Picocontainer, and Avalon.

Let me address Avalon first, because it's the easiest to dismiss. Avalon supports type 1 IoC only, which means that IoC is defined through an interface. Type 1 IoC is too rough to work with because it ties your application objects too closely to the framework. Thus, in Avalon, your application objects must implement Avalon-specific interfaces. Type 1 IoC is all but a deprecated concept and that is evidenced by the fact that the Avalon project is a dead project.

I've worked quite a bit with PicoContainer (it was the first IoC container I ever dealt with). Pico is constructor-injection based by nature. Sure, it supports setter-injection, but it's tedious to use.

Also, it's either very difficult or impossible (I'm leaning toward impossible) to have more than one instance of the same bean in the container. The reason has to do with how Pico autowires your beans together. If there's more than one of something, how can Pico choose? Even Spring, when autowiring by constructor or by type, will throw an exception of more than one of the same type exists in the container (an exception is better than Spring guessing wrong about which instance to wire).

The biggest thing I can say against Pico is that it's documentation is spotty. They spend more time in their documentation defending their constructor-injection stance than telling you how to use the container.

Before I move on to Hivemind, let me say one more thing about Pico...if you like Pico's way of always auto-wiring by constructor (I can't imagine why you'd like that, but if you do), then you can get Spring to do that pretty easily. The following <beans> declaration makes Spring behave a lot like Pico:



I've only tinkered with Hivemind a little. From what I see and from a DI-only perspective, Hivemind looks to be on par with Spring. Where Hivemind fails to compare with Spring is in the other services and subframeworks that Spring provides. Hivemind's AOP support is trivial compared to Spring's AOP subframework. And Hivemind doesn't come with any of the other stuff (MVC, ORM-integration, declarative transactions, etc, etc) that Spring comes with. And, as I've stated before, Hivemind doesn't have quite the wealth of info available that Spring has. Other than that, Hivemind is nice...Spring has a lot more momentum, though.

Then there's Spring. Spring has a wealth of services and features beyond the IoC container. Google for Spring and you'll find tons more information than you would with Hivemind, Pico, or Avalon combined. And there still isn't even a single book published on Hivemind, Pico, or Avalon. I personally own 3 Spring books (5 if you count Rod's first two books) and there's two more on the way. That's all to say that Spring has a lot more momentum than any of the other IoC containers.