Guice Flaw

It is not really a flaw, more of an opportunity missed. I have just spent a wee while converting a project from semi-spring to guice. Anecdotally, I prefer to refer to this exercise as goosing, and I don't care what your culture currently associates with that word, Google is a global culture and the act of exacting its influence may take over the definition as far as I am concerned, big up for the living English language! Mr Knowles will hate me.

Back to the techie end...
Moving to Java 1.5/5.0 as our LCD of new java products led us to re-evaluate various existing design choices. The conclusion was that big steps need to be taken, quite simply because they can and should be taken (cost is worth it). Guice appears to be the ideal selection for such a way forward because you can always regress to a Spring, Pico or home grown framework without having to rewrite too much. But having gone through such an exercise there is one remaining doubt; which is the flaw of the title.

The doubt/flaw is that seriously used Guice requires you to transfer your 'design of linkage' to a module class, which previously was in a mixture of xml and lookup code. The people who designed Guice did the right thing by making the Binder class an interface so that you can unit test your modules, which helps, but that still leaves two issues:

1. It is hard to support build systems for multiple target environments. The modules tend towards the monolithic, and even if they are testable themselves, there are still better techniques for this kind of application extensibility, e.g. OSGI. I suggest that you use inheritance and delegation in the modules, but my issue is still that the linkage becomes a development exercise in its own right, and one that required in depth Guice knowledge to boot.
2. If you try to write a generic server style application, e.g. another web container, then you are forced to create a 'team' pattern between a Module implementation and its domain specific business classes, because they have to work together in this type of context.

I managed to resolve the build issues of multiple targets by using a 'ClasspathScanner' to discover indicator files that pointed to Module classes that constituted the application. For example the Swing app would have a jar in its classpath that had a Module indicator pointing at the swing module class to be included in the injection list, while the war build would be constructed using the modules in the war path. But I think Guice should take a step in this direction, as its own processes would be best suited to this 'discovery' phase.

I suppose what I am getting at is that the strong typing of Guice is both a pain and a pleasure. I hope Guice does for the J2EE framework world what Ada95 did for the fast jets of today, i.e. try and balance the industry concerns with the realities of development. Luckily the nature of DI is such that all these things are soluble, you just might have to learn another framework in the process. The pleasure is that it is testable, the pain is that you have to code it rather than just configure it.