Sunday, April 13, 2008

Module management and Dependecy injection

I'm trying to choose some framework which will help us to manage modules and dependencies after modularization of Robocode.
There are several criteria
  • small
  • fast
  • easy to use
  • low impact on code
  • easy to configure when user adds new module at runtime

I would like to hear your opinion about weight of criteria above.
I have hard time to choose right one, because lot of Java specific names are new to me. Half of articles on the Internet is kind of holy war again, so it is thought to find informed and balanced article.
I will  try to summarize what I've learned about possibilities.

We have three problems
  • 1) how to friendly add .jar plugin to classpath
  • 2) how to manage dependencies
  • 3) how to manage different versions of plugins or their dependencies on same classpath
  • 4) we also need to consider licensing. I'm not an licensing expert, though.

Solution for 3) and also 1)

It is quite difficult problem.
There are some standard solutions to the problem
OSGI
http://felix.apache.org/site/index.html
http://www.eclipse.org/equinox/
http://www.knopflerfish.org/

JPF
http://jpf.sourceforge.net/

I propose to ignore the problem, because solution is too heavy for our needs. Ignoring c) may lead to necessity of recompilation of cascade of plugins when some of them will change heavily. I believe that we could live with that.

Update: I have found concierge, which looks pretty small = 80 KB. I should try to use it.

Solution for 2)

This problem is nicely solved by various Dependecy injection frameworks.

Spring, Spring JavaConfig
+ de facto standard
- too heavy

Guice
+ fast
+ quite nice
+ type safe
* no that big, but still ....
- no external configuration (XML)
- code will become dependent on it because annotations

PicoContainer
+ small
* all wiring is done in code
- no external configuration (XML)

NanoContainer (buid on top of PicoContainer)
+basic xml configuration
+ still very small (176KB)
+ able to solve problem 1)
- lack of documentation

Conclusion

For our use case I like most PicoContainer+NanoContainer.
It solves problem 1) and 2), with small size, with possibility of XML configuration, and our components could be independent on it's namespaces. I tested it on small test project with one core and one plugged jar, and with XML config. I was also able to pass parameter to constructor from XML.

I'm interested to hear other opinions. Thanks!

2 comments:

Assault Bunny said...

I see that you have really researched this well, finding a good dependancy injection framework these days is a bit tricky.I am not sure about the other languages but c# doesnt have any experienced yet compact framework .

I have looked at spring but for the amount of functionality i was going to use it was overkill for my app. The Nanocontainer looks worth investigating.

Thanks again for the info.

Pavel Šavara said...

For C# I used Castle. Quite cool.
http://www.castleproject.org/container/index.html

And tried Unity in some early stage, so I was not satisfied with XML config. Maybe it is better now.
http://www.codeplex.com/unity

There is also
http://www.springframework.net/
But I didn't have chance to use it yet.

I don't know if there is anything like OSGI for .NET
I also wonder what will happen if we load more different versions of same component at once into same application domain. This is one of scenarios solved by OSGI & classloaders on Java.