Write a Spring comparison answer

DUDES!

If your comment to a JIRA issue is relevant to the resolution of the issue, please put the comment in JIRA instead of on the mailing list. Otherwise the comments are likely to be overseen when the issue is resolved.

Aiiit?

There's a lot of good comments on the list:

http://lists.codehaus.org/pipermail/picocontainer-dev/2003-August/000924.html

that should have been inside this JIRA issue as comments.

points from the thread:
"Mike"
"Spring is a J2EE application framework. As such, IoC is only one of its concerns. Pico, on the otherhand, is concerned only with IoC. There is no reason, therefore, than Pico could not provide Spring's IoC service (well, Nano more accurately). Service Offering:

Spring offers little in the way of "service" with respect to IoC. A developer using Spring has to state using XML which bean instances should be pushed as dependencies to another bean. This is not a whole lot more than calling setXXX() methods yourself. In fact, some would argue than just calling the setXXX() methods directly in Java would be more efficient. The dependency provision mechanism is pluggable in Spring however, so you are not bound to XML.

Pico, being a pure-play IoC container, does offer service with respect to IoC. Once dependencies are stated using constructors, Pico figures out the dependency tree on a system wide basis, and pushes the instances required to satisfy each dependency. This is a much more efficient and pleasant way of working.

Contract Enforcement:

Since Spring uses setXXX() methods to accept dependencies, its possible that service methods be called on a bean that has unsatisfied dependencies. To solve this problem, Spring provides an afterPropertiesSet() method that is called after dependency satisfaction and before service method calling. This is your chance to catch unsatisfied dependencies, but you have to remember to do it.

Pico solves this more cleanly. Given that null checking can be done in constructors in Pico, its not possible for a bean with unsatisfied dependencies to come into existence. There is "no two stage process". The result is more readable and more defensive code. "

(end Mike)

Dan North:
One change I would make to your excellent summary would be in the last
sentence. One of the great unsung(ish) things about IoC is how well it
encourages what Joshua Bloch calls good citizens. This is along the
lines of the fail-fast idea that an object or component is never in an
inconsistent state: just by existing it is ready to provide a service.
So you don't get this constructor -> setters -> post setters model with a scary inconsistent bit in the middle - by the time the object is constructed it is ready to roll. In fact this leads to less defensive coding - you don't need to do state checks on objects you collaberate with, the objects themselves need far less internal consistency checks etc.

Anyway, I'm sure you know all this, so my point was that IoC leads to
less defensive coding rather than more. Especially when you couple it
with the Null Object pattern and other Jolly Good Ideas.

(end Dan North)

I think a direct comparison between Spring and PicoContainer is wrong beacuse Spring aims to be as feature-complete as it can in terms of J2EE functionality, while the PicoContainer core does not do J2EE per se, since it has no external dependencies (besides JUnit.)

From the Spring doc:
"Pico's support for primitive parameters (including Strings) is poor. They suffer from the same limitations as component dependencies, that is, just one instance of any given type for each component. Multiple int, boolean, or String parameters for a single component are very common; Pico is currently not suitable for such requirements."
– Fixed with the latest set of component constructor resolution.

"Using existing classes is hard with PicoContainer: You have to subclass and write magic constructors there, or even worse, wrap the existing class. Spring has the ability to work with any existing JavaBean."
– JavaBeans are not Good Citizens because of unsafe states (as explained in http://lsd.student.utwente.nl/jicarilla/JavaBeansConsideredEvil), and because they don't promote proper OO. They reduce classes to simple data containers.

"Inheritance is painful and error-prone when constructor chaining is required. Spring can use final bean properties to avoid errors. A constructor (or any method) with 10 arguments is a code smell and suggests refactoring into an initializer object. Spring can easily support such an initializer via a bean reference."
– Agreed, a constructor with 10 arguments is a code smell. But PicoContainer does not promote that that. It's an indication that the component is "doing too much" and should be split into smaller components.

"JavaBeans are an elegant part of core Java: Why not use them? PicoContainer objects will need to follow a unique constructor pattern."
– They are not part of core Java. They are just a construct invented for GUI code. On the other hand, constructors and final members which may only be set in constructors are core Java.

"Constructors are less obvious in IDEs than bean properties. It's trivial to see the properties on any object."
– But IDE's that compile on fly will catch you if you have unset properties. Bean property checking is deferred until runtime.

"The main argument for Pico's constructor-based "Type 3 IoC" approach is that it cannot miss any dependencies; it guarantees a fully configured instance. But why should every component need to receive instances for all possible dependencies and parameters? A bean-based approach, aka "Type 2 IoC" but without enabler interfaces, allows for optional dependencies without any hassle. We consider such flexibility more important than to avoid missing dependencies at any cost."
– This question is in line Pico's Good Citizen/core Java language aproach, versus Spring's J2EE-oriented, runtime configuration approach. Thus, Spring embraces XML runtime configuration, PicoContainer rejects it since it provides weak typing (am I right?).

It's in confluence:
http://docs.codehaus.org/display/PICO/Comparison+with+other+lightweight+containers