Binding an interface before binding the concrete class fails, but reversing the order works.

[GoogleCodeExporter]

bind(IFoo.class).toProvider(...)
bind(Foo.class).toProvider(...)

fails

while

bind(Foo.class).toProvider(...)
bind(IFoo.class).toProvider(...)

succeeds (Foo implements IFoo)

Original issue reported on code.google.com by ron.gr...@gmail.com on 25 Nov 2009 at 1:01

[GoogleCodeExporter]

Which version of Guice are you using? I believe this was fixed in v2.

Original comment by limpbizkit on 25 Nov 2009 at 4:46

[GoogleCodeExporter]

We're using Guice 2.0

Original comment by ron.gr...@gmail.com on 25 Nov 2009 at 5:05

[GoogleCodeExporter]

Could you please supply a small test case? This doesn't appear to the be the 
case in 
general.

Original comment by limpbizkit on 26 Nov 2009 at 12:27

[GoogleCodeExporter]

Sorry, I was mistaken - the real problem is that in the first code sample, 
Foo's 
provider is called eagerly and not lazily. My test case involved binding IFoo 
to a mock 
and Foo to an 'error' provider that always throws an exception - I wanted to 
make sure 
nobody is using Foo instead of IFoo.

In the first version, the binding itself invoked the provider.

Original comment by ron.gr...@gmail.com on 27 Nov 2009 at 8:15

[GoogleCodeExporter]

Original comment by limpbizkit on 27 Nov 2009 at 5:59

• Changed state: Invalid

[GoogleCodeExporter]

This is not invalid, there is a real issue it's just not the one I originally 
reported 
- reread my previous comment.

You can rename this issue to "A concrete class's provider is not lazy after 
binding the 
interface".

Original comment by ron.gr...@gmail.com on 27 Nov 2009 at 6:06

[GoogleCodeExporter]

Could you attach a small testcase?

Original comment by limpbizkit on 27 Nov 2009 at 11:34

[GoogleCodeExporter]

Odd, it doesn't reproduce. 

Original comment by ron.gr...@gmail.com on 29 Nov 2009 at 9:29