comparison.md

layout	title
doc	Comparison

See Also Considered Harmful Motivation # Comparison In the below tables the features of 4 frameworks are compared with each other. This is a by no means a fair comparison as it builds upon the opinions of the author of silk. Features are judged by their influence on application design and the development process. An influence considered good is indicated green, a fair one yellow and a bad one red. Neutral information is kept gray. This table highlighting is turned **off** by default.

Concepts or techniques that are considered harmful have dark red text as well. Missing or unsure information is indicated by a `'?'`.

Library

Highlight on/off

Feature	Spring	Guice	pico-container	Silk
Version	3.x	3.x	2.14.x	0.7
Archive Size	several MB	> 650KB + plug-ins	> 300KB + gems	189KB
Further dependencies	good dozen	few	none	none

API

Highlight on/off

Feature	Spring	Guice	pico-container	Silk
Methods in injector/context	20+	20+	14	1 (example)having 1 argument

Concept

Highlight on/off

Feature	Spring	Guice	pico-container	Silk
Container model	flat instances	flat instances	hierarchical instances explicit modeled	hierarchical instances "production rules"
Configuration style	static XML, annotation	static + programmatic annotation + fluent interface	static + programmatic composition + fluent interface + annotation	programmatic declarativefluent interface
Wiring style	automatic "scan" by name or type	explicit by name and type	explicit by name and type	explicit name + type + hierarchy
Wiring Transparency / Independence	yes XML or config-classes	no annotations required	yes (except annotation feat.)	yes pure fluent interface
"External" code handlinge.g. a external lib or JRE type	limited (name/type wiring only)	indirect requires Provider	limited (to some features)	as ownuniform
Coupling styleHow interface/impl. is brought together	referenceable	loose	referenceable	loose

Types

Highlight on/off

Feature	Spring	Guice	pico-container	Silk
Generics support(Consider same type with different generic to be different)	no	yes each a literal class!	case-related	yes Type instance
Generic type safty	-	compile time	-	largely compile timefull at runtime
Wildcard generics	-	yesexplicit via literal	-	yes
Primitive types handling	?	primitive == wrapper	?	primitive == wrapper
Bind to all (generic) supertypes	no	no	no	yes
Type links	no	yes	no	yes

Injection

Highlight on/off

Feature	Spring	Guice	pico-container	Silk
Annotation guidance (considered harmful) Why?	required XML alternative	required	less important alternative	no need
Constructor injection	yes annotations or XML	yes requires annotations	idiomatic most to few args	idiomatic fluent interfacemany options
Field injection(considered harmful) Why?	yes annotations	idiomatic annotations	yes named or annotations	no
Setter injection (considered harmful) Why?	idiomaticnamed, annotations or XML	yes annotations	yes name or type	no
Factory methods	yes named XML, annotations	yes annotations	yes convention, programmatic	yes fluent interface
Static injection(considered harmful) Why?	yes named XML + annotations	yes annotations	no?	no
Method interceptiontechnique	yes aspects	yes aspects	yes programmatic	services programmatic
Providers (lazy indirection)	yes	idiomatic annotations	no	optional bridge via fluent interface
Reinection(considered harmful) Why?	yes setters	no use indirection	explicit call-side programmatic	no use indirection
Optional injection(considered harmful)	no?	yes annotations	no?	no
Mixed injection(assisted injection)	no?	yes annotations	no?	services
Post-construction hook	yes annotations?	yes annotations?	yes(lifecycles)	through custom Supplier only

Modularity

Highlight on/off

Feature	Spring	Guice	pico-container	Silk
Arrays	no	no	idiomaticimplicit available	idiomaticimplicit available
Collections List/Sets/Maps	java.utilexplicit in XML	java.util (via plugin-in)fluent interface	java.utilexplicit programmatic	any(via bridge)fluent interface
Multibinds	manual, explicit XML tags	manual, explicit, loose coupled fluent interface	manual, explicit programmatic	autom., implicit, loose coupled fluent interface
Sequence of declarations	crucial	crucial	crucial	irrelevant

Variants (Module Combinability)

Highlight on/off

A _variant_ should be understand as a slightly different _form_ of the _module structure_, a permutation of the application configuration/composition. How can those be build, viewed, understand, and combined with other _variants_ ?

Feature	Spring	Guice	pico-container	Silk
Creation techniqueUsage	overridesXML filesannotated config classes	overridesModule classes	?	install/uninstallfluent interface
Perspective	combined	combined	?	isolated
Composition	not combinable	not combinable	?	combinable

Applicability Restrictiveness

Highlight on/off

In what ways can _binds_ be limited, how exact or _narrow_ are they ?

Feature	Spring	Guice	pico-container	Silk
Principle	local per file	local modules	programmatic filtersper case	type hierarchy + package-sets + injection hierarchy
Specific package (set)(with or without sub-packages)	no	no	possiblenot build in	yesfluent-interface
Specific classalso with wild-card types	nearly	yesexplicit via literal	yesgems filter util	yesfluent-interface
Specific interfaceincl. all implementations	no	no	yesgems filter util	yesfluent-interface
Specific parent instancealso specific grandparents	no	no	no	yesfluent-interface

Scopes

Highlight on/off

Feature	Spring	Guice	pico-container	Silk
Default scope	singleton	injection	singleton	singleton
Custom scopesdifficulty	advanced	advanced	medium(life-cycles)	simple
Available scopes	singleton, injection, request, session	singleton, injection request, session via plug-in	programmatic life-cycles	singleton, injection, per dependency type, per receiver type, ...

Performance

Highlight on/off

There seamed to be no actual numbers on performance. I had no time to do proper tests including all 4 frameworks yet but I would like to get these numbers if available somewhere or by myself if needed. Until than I can just give indications based on older measurements I found and personal experience gained in years of usage (not pico-container) or expectation (pico).

Feature	Spring	Guice	pico-container	Silk
Bootstrapping	slower than guice	stated that it is fast	about as guice?	about as guice?
Object Creation	stated that it is slower than guice	stated that it is fast	about as guice?	about as guice?

Error Behaviour

Highlight on/off

Feature	Spring	Guice	pico-container	Silk
Dependency cycles	viable setter only	viable proxies	viable for interface	illegal
Detection of a cyclic dependencies error	runtime(bootstrapping)	-	?	runtime(bootstrapping)
Scope faults(e.g. injecting request scoped into a singleton)	?	not detected	not possible(self managing objects)	at injection
Ambiguous binding error	eager	lazy	lazy	eager

Noteworthy

• With Silk all binds are defined by just using the fluent Binder interface within Bundle and Module classes. There are no exceptions to this, no overrides or annonymous classes needed, no error prone visiblity exports or similar hard to maintain techniques.