With respect to "various various principles and practical concerns" -- I felt as you did, once.
To paraphrase Churchill: It has been said that @Inject is the worst form of integration except all the others that have been tried. At first I found working with the annotations a little difficult, but then I started to respect them, my staff started to like them, and then you're home free. As a simple example, being able to open an interface, see @Singleton at the top and by that know the requirements of any implementation (with respect to thread safety, for example) is really a great thing. (You require that in javadoc anyway, right? Keeping that doc and @Singleton in the same file means they won't drift.) Putting the information close to your users means you don't have to keep saying "did you check the module" when somebody has a question. Annotations also scale well, since they reduce programmer-contention on the module file(s). So by all means, you can do everything you need to do in the modules, but I encourage you to at least give the @alternative a try. You might like it. -d On Dec 31 2009, 4:47 pm, JN <[email protected]> wrote: > I'm looking seriously into the possibility of using guice for our > project. However, I'm extremely reluctant to pepper our interfaces > and implementation classes with guice injections (based on various > principles and practical concerns, I don't find it a good idea). I'd > like to use guice without using annotations, although I suspect it's > not possible. > > Skimming the documentation, it seems like most of the annotations can > be obviated by doing more work in the module. However, doing an > injection (I'd prefer constructor injection) seems to *require* the > @Inject annotation. Is there any way around this? > > Also, if I caved on the @Inject annotation on constructors, is it > realistic to use Guice in a large, complex application and use guice > in complex ways without using the other annotations (= code things > explicitly in the modules)? > > Are people happy with the annotations-mandatory approach? Is there no > demand for alternate means of configuration? I'd rather just specify > everything explicitly in the module, even if it's a little more > verbose. > > Any other good DI containers worth exploring? Stuff I'm aware of: > > Spring -- too much baggage (I want something that only does DI) > PicoContainer -- looks interesting, but guice community seems much > larger. I'm gonna look into it a little more. > yan -- looks dead, so no way I can use; but looked interesting > butterfly -- no Java-based config (need traceability in IDE; not > interested in any non-Java approach) > > Thanks, > Jim -- You received this message because you are subscribed to the Google Groups "google-guice" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-guice?hl=en.
