Why yes, if you don't mind the runtime dependency, then you get the ideal solution: your Toolkit.getDefaultToolkit()-style methods, which you have for the benefit of your users who don't use Guice themselves, can simply delegate to their own private injector to wire everything up for you. That's nice.
Some problems may result if a user mixes using Guice directly with using these statics, though, as they'll end up with two different injectors. On Fri, Jun 5, 2009 at 4:50 PM, Gili Tzabari <[email protected]> wrote: > > Hi Kevin, > > I am not so concerned about @Inject annotations or runtime costs so > much as "API pollution". For example, I worry users would be off-put by > having to do: > > Injector.getClass(Toolkit.class); > > instead of > > Toolkit.getDefaultToolkit() > > Are you suggesting that I should expose the latter method that > invokes > the former internally? From a usability point of view, factory methods > look a lot nicer coming off the class than having to go through an extra > level of indirection (Injector)... > > Gili > > Kevin Bourrillion wrote: > > The goal of Guice is for your code to not truly depend on it. However, > > the fact that @Inject and interfaces like Provider are not in the JDK -- > > yet! <http://jcp.org/en/jsr/detail?id=330> -- means you do end up having > > to depend on Guice in these small ways. Still, you can keep your Module > > definitions in a separate artifact, and you can offer Spring > > configurations as well or even static factories that wire up your nice > > DI-friendly classes by hand if that's something you want to do. The > > guice JAR file that would be required at runtime could be very small. > > > > > > On Fri, Jun 5, 2009 at 1:32 PM, Gili <[email protected] > > <mailto:[email protected]>> wrote: > > > > > > Hi, > > > > I'm about to publish an open-source Java library and I was thinking > > that it would benefit from using Guice in a couple of places to > > improve testability. My next thought is that users would avoid my > > library if I force Guice on them. I don't want to cross the line > > between providing a library to providing a framework. > > > > Has anyone else run across this before? Is this the reason we rarely > > see Guice or Spring being used by other open-source libraries? > > > > I use Guice everywhere in my internal application code, but I'd be > > reluctant to use a library if it exposed IoC through its API. > > > > Gili > > > > > > > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
