Multibinder Bindings Don't Always Respect Singleton Scope

From nachtrabe on December 11, 2013 13:10:31

Description of the issue: When using the multibinder, if you use binder.addBinding().to(B.class).in(Singleton.class); it will not enforce the singleton nature on that object, but using the @`Singleton` annotation directly will. Steps to reproduce: 1. Create a Multibinder.newSetBinder instance with an interface. 2. Bind an implementation using `.in(Singleton.class)`. 3. Bind another implementation annotated with @Singleton. 4. Inspect that the instances retrieved are not singletons in the cases where .in(Singleton.class) was used, but are in the cases where ``@Singleton was used.

Expected behavior:

- I’d expect for .in(Singleton.class) to work, to not be exposed, or to throw an exception.

The attached tests illustrate the problem: getInstance_ofSet_ContainsB and getInstance_ofB_IsIdentical both fail under both Guice 3.0 and Guice 4.0-beta.

Attachment: gist    GuiceTest.java

_Original issue: http://code.google.com/p/google-guice/issues/detail?id=791_

[gjoseph]

Sam and OP, I got this to work this way: (with help from @tmattsson) Op’s original binding:

            binder.addBinding().to(B.class).in(Singleton.class);

replaced by this:

            binder().bind(B.class).in(Singleton.class);
            binder.addBinding().to(Key.get(B.class));

makes it work as we expect. WDYT ?

[gjoseph]

Sure; that works if I have a Module in that same package. I’m dealing with a ball of legacy code, and can’t really do that (or ensure that everyone does it, anyway). That said, the extra binding is also probably no big deal, but I have no way of checking (in plugin-based environment, my only option now is to let the bindings fail at runtime, and it might not fail for everyone)