Spring, Pico and Nuts Compared

In this page and sub-pages, we try to put together some feature-by-feature comparison between Spring, Pico/Nano and Yan/Nuts.

This comparison is focused on "IOC container" functionalities. So toolkits such as Spring DAO, Spring MVC are not taken into consideration. A good IOC container should be able to plug&play these services any way.

Throughout the comparisons, I tried to be objective. Yet, due to my limited knowledge on the compared containers, it is certainly possible that some facts and comparisons are inaccurate or simply incorrect. I'll be grateful for any correction.

We'll start with a big fat comparison table:

Features  Spring  Pico  Yan/Nuts
xml configuration
Yes  Through Nano Container
Yes
Auto wiring
Yes
Yes
Yes
Manual wiring
Yes
Yes
Yes
Extensible auto wiring support
No
No
Yes. Custom Autowire Mode - EJB3 style
Auto Bean Registration
No

Yes
Life cycle
Singleton only
Singleton only
Both singleton and prototype
Eager Instantiation
Default for all singletons
Yes
Yes
Lazy Instantiation
Yes
Yes
Default
Parametered and ad-hoc life cycle
No
No
Through <lifecycle> tag
Constructor Injection
Yes Yes
Yes
Setter Injection
Yes
Yes
Yes
Factory Method Injection
Yes
Yes
Yes
Referencing Field
FieldRetrievingFactoryBean
Implement ComponentAdapter
Through <field> tag.
Anonymous sub-bean
Yes No
Yes
Ad-hoc bean combination
No No
Through <sequence> or <callcc> tags
Concise collection literal
No
No
Yes
named local bean
No
No
Through <local> tag
abstract bean
Yes

No
bean function
no

yes
import module
Yes
Yes
Yes
module private beans
No
No
Through "export" and "hide" attribute of <module>
Selective import by bean names
No
No
Through "includes" and "excludes" attribute of <import>
Import with namespace
No
No
Through "namespace" attribute of <import>
Singleton bean with prototype property
Requires Cglib and bytecode generation
ComponentAdapter combination
Through component combination
Dependency Injection for objects not managed by container
Supported at the cost of Spring API dependency
No
Through <function> and <factory> tag
Extensible tag library
No. But FactoryBean is a substitute
No
By implementing subclasses of Nut
Configuration unit-testable within configuration file.
No
No
By using <sequence> together with <assertEqual>, <assertSame>, <if>, <unless>, <fail> etc.
autoproxy
Yes

No
Custom PropertyEditor
Yes
Yes
Yes
Container hierarchy
Yes
Yes
Yes
AOP support
Both Spring AOP and AspectJ
Via dynaop
Any AOP solution can be plugged in. An integration package for spring AOP is provided out-of-box.
Declarative Transactional support
Yes
  No. But Spring's declarative transaction support is integrated.
Scripting language support
Not yet
Nano Container
Not yet

Details:

 


Created by benyu
On Mon Nov 28 15:38:13 CST 2005
Using TimTam

Labels

 
(None)
  1. Dec 07, 2005

    Paul-Michael Bauer says:

    Spring supports both singleton and prototype beans.

    Spring supports both singleton and prototype beans.

  2. Dec 07, 2005

    benyu says:

    The following is copied from Spring Reference 3.4.1.2, which convinced me that "...

    The following is copied from Spring Reference 3.4.1.2, which convinced me that "prototype" is not supported:

    Important note: when deploying a bean in the prototype mode, the lifecycle of the bean changes slightly. By definition, Spring cannot manage the complete lifecycle of a non-singleton/prototype bean, since after it is created, it is given to the client and the container does not keep track of it at all any longer. You can think of Spring's role when talking about a non-singleton/prototype bean as a replacement for the 'new' operator. Any lifecycle aspects past that point have to be handled by the client. The lifecycle of a bean in the BeanFactory is further described in Section 3.4.1, "Lifecycle interfaces".

  3. Dec 07, 2005

    benyu says:

    This is lifecyclemanagement related only, btw. Spring does support prototype bea...

    This is lifecycle-management related only, btw.
    Spring does support prototype beans, but not the lifecycles of them.