Using Guice in public libraries

[Gili]

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

[Kevin Bourrillion]

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! -- 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.

[Gili Tzabari]

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

[Kevin Bourrillion]

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.

[Johannes Schneider]

Gili Tzabari wrote:
> Hi Kevin,
>
> I am not so concerned about @Inject annotations

Well, you should be. Since Guice does *not* provide a small jar
containing only the annotations, you either have to add the complete
guice jar as dependency or provide your own jar.
http://code.google.com/p/google-guice/issues/detail?id=106



Regards,

Johannes