provider methods can't bind eager singletons

[GoogleCodeExporter]

We need an @Eager or something for provider methods.

Original issue reported on code.google.com by medo...@gmail.com on 25 Jun 2008 at 1:39

[GoogleCodeExporter]

Why isn't Stage.PRODUCTION sufficient?

Original comment by limpbizkit on 25 Jun 2008 at 3:19

• Added labels: Priority-Low
• Removed labels: Priority-Medium

[GoogleCodeExporter]

Original comment by limpbizkit on 25 Jun 2008 at 3:20

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

Because we do development in Stage.DEVELOPMENT but still want things like RMI
services to start up.  It's not a matter of performance, but rather correctness.

Original comment by medo...@gmail.com on 25 Jun 2008 at 3:31

[GoogleCodeExporter]

2008. Why hasn't this been addressed yet?

Original comment by psavi...@google.com on 16 Jul 2010 at 9:41

[GoogleCodeExporter]

Patches are very welcome!  (I haven't been able to think of a clean way to add 
this into the API.. so if someone else can, please do!)

Original comment by sberlin on 16 Jul 2010 at 10:58

[GoogleCodeExporter]

Why can't you just do bind(type).asEagerSingleton(); and let it figure out 
where to get the instance from (e.g. @Provides, etc.) ?

Original comment by rdamazio@gmail.com on 17 Jul 2010 at 6:36

[GoogleCodeExporter]

At this point, .asEagerSingleton() seems like a viable option - I'm going to 
"NeedInfo" on this - if you still think we need something in the API or 
behaviour beyond binding eagerly directly, please update this bug.

Original comment by cgruber@google.com on 16 Jul 2012 at 6:18

• Changed state: NeedInfo
• Added labels: Component-Core

[GoogleCodeExporter]

I don't believe this approach works. For example, the following code:

    final Module module = new AbstractModule() {
      @Override protected void configure() {
        bind(Integer.class).asEagerSingleton();
      }

      @Provides Integer provideInteger() {
        return 0;
      }
    };
    createInjector(module);

produces the errors:

1) A binding to java.lang.Integer was already configured
2) Could not find a suitable constructor in java.lang.Integer.

Original comment by chrispur...@google.com on 8 Apr 2013 at 3:13

[GoogleCodeExporter]

Original comment by cgruber@google.com on 18 Nov 2013 at 9:10

• Changed state: Acknowledged

[GoogleCodeExporter]

Why is this an enhancement and not a defect? What's the best way to work around 
this?

Original comment by JoshBB...@gmail.com on 19 Feb 2014 at 7:09

[GoogleCodeExporter]

It's an enhancement because you're left with clunky Guice 1.0 semantics as a 
workaround:

public class MyModule extends AbstractModule {

  static class MyProvider implements Provider<Foo> {
    @Inject Bar bar;
    @Inject Baz baz;

    public Foo get() {
      return Foo.from(bar, baz);
    }
  }

  public void configure() {
    bind(Foo.class).toProvider(MyProvider.class).asEagerSingleton();
  }
}

Original comment by kha...@google.com on 19 Feb 2014 at 7:14

[GoogleCodeExporter]

Thank you.

Original comment by JoshBB...@gmail.com on 19 Feb 2014 at 7:17