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!

Friday, April 11, 2008

Robocode Modules - draft

I quickly put together proposal of modularization. I didn't yet checked it against current code, so I probably missed something. The names do not match current names of classes. Interfaces are not yet designed at all. It's just first draft. Robocode