Provider vs. guava Supplier and future JDK8 Supplier

[Romain Gilles]

Hi all,

I would like to know how can I had the same type of feature of automatic bindings of Providers (guice or javax-inject) for Suppliers (guave or java 8)?

I would like to do something like that:

public class MyModule extends AbstractModule {

    @Override

    protected void configure() {

        bind(MyInterface.class).to(MyImpl.class);

    }

}

And then be able to indefferently inject it in the following use cases without extra work:

class MyClient {

    private final Provider<MyInterface> myInterfaceProvider;

    private final Supplier<MyInterface> myInterfaceSupplier;

    @Inject

    MyClient(Provider<MyInterface> myInterfaceProvider, Supplier<MyInterface> myInterfaceSupplier) {

        ...

    }

    ...

}

Thanks,

Romain.

[Christian Gruber]

Are you asking if you can somehow have an automatic injection of
Supplier<Foo> the way we special-case injecting Provider<Foo>?

At present, that isn't an automatic thing, the way it is with Provider.
Provider is a core part of dependency injection infrastructure for
Guice, and one is always implicitly there for every binding. That is
not true of Supplier.

However, what you might be looking for is, effectively Assisted Inject,
which is similar, but it won't inherently implement Supplier. You can
make a provides binding that simply binds a Supplier<Foo> to an
anonymous inner implementation assisted-inject factory.. But that's
somewhat manual.

If you are willing to wait a bit, Google is going to release
AutoFactory, which is a very similar system to Assisted-Inject in
concept, but using code-generation. It has a feature slated that would
allow someone to specify an interface like Supplier and it will generate
a factory method (with no parameters) on the generated factory for that
Supplier's only method. I suspect this might meet your needs.

Christian.

> --
> You received this message because you are subscribed to the Google
> Groups "google-guice" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to google-guice...@googlegroups.com.
> To post to this group, send email to google...@googlegroups.com.
> Visit this group at http://groups.google.com/group/google-guice.
> For more options, visit https://groups.google.com/groups/opt_out.


Christian Gruber :: Google, Inc. :: Java Core Libraries :: Dependency
Injection
email: cgr...@google.com :::: mobile: +1 (646) 807-9839

[Christian Gruber]

Greg meant http://github.com/google/auto

It's available in source, but not released to maven.

Christian.

On 21 Oct 2013, at 9:25, Gregory Kick wrote:

> To clarify about @AutoFactory:
> 1) It is available now. It hasn't been "released" due to a buggy
> interaction with Dagger, but you can find it in 3p/java_src/auto right
> now.
> 2) Supplier is a ways off just due to the generics, but you should be
> able
> to hack around it with something like the following:
>
> interface FooSupplier extends Supplier<Foo>
>
> That's obviously not idea, but inferring proper generics for things
> like
> Supplier is a bit tricky.
>
>
> On Mon, Oct 21, 2013 at 11:19 AM, Christian Gruber
> <cgr...@google.com>wrote:

>>> bind(MyInterface.class).to(**MyImpl.class);

>>> }
>>> }
>>>
>>> And then be able to indefferently inject it in the following use
>>> cases
>>> without extra work:
>>>
>>> class MyClient {
>>> private final Provider<MyInterface> myInterfaceProvider;
>>> private final Supplier<MyInterface> myInterfaceSupplier;
>>> @Inject
>>> MyClient(Provider<MyInterface> myInterfaceProvider,
>>> Supplier<MyInterface> myInterfaceSupplier) {
>>> ...
>>> }
>>> ...
>>> }
>>>
>>> Thanks,
>>>
>>> Romain.
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups
>>> "google-guice" group.
>>> To unsubscribe from this group and stop receiving emails from it,
>>> send an
>>> email to

>>> google-guice+unsubscribe@**googlegroups.com<google-guice%2Bunsu...@googlegroups.com>

>>> .
>>> To post to this group, send email to google...@googlegroups.com.
>>> Visit this group at

>>> http://groups.google.com/**group/google-guice<http://groups.google.com/group/google-guice>

>>> .
>>> For more options, visit

>>> https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out>

>>> .
>>>
>>
>>
>> Christian Gruber :: Google, Inc. :: Java Core Libraries :: Dependency
>> Injection
>> email: cgr...@google.com :::: mobile: +1 (646) 807-9839
>>
>
>
>

> --
> Greg Kick
> Java Core Libraries Team

[Cédric Beust ♔]

On Mon, Oct 21, 2013 at 9:19 AM, Christian Gruber <cgr...@google.com> wrote:

If you are willing to wait a bit, Google is going to release AutoFactory, which is a very similar system to Assisted-Inject in concept, but using code-generation.

Just curious: does this mean that assisted injection might come to Dagger in the form of generated code?

-- 

Cédric

[Gregory Kick]

As it turns out, when you're generating code, assisted injection doesn't even need to be part of Dagger (or Guice for that matter).  We're calling it @AutoFactory.  It already works with Guice, but we have a blocking bug in Dagger.  As soon as that's resolved we'll do our first release.

[Cédric Beust ♔]

On Mon, Oct 21, 2013 at 12:18 PM, Gregory Kick <g...@google.com> wrote:

As it turns out, when you're generating code, assisted injection doesn't even need to be part of Dagger (or Guice for that matter).  

Yeah, was thinking about this. The reason why assisted injection exists at all is because Java doesn't support default parameters. If you are able to generate the factory that will instantiate this class, nothing stops the generator from creating a factory with these fields already initialized with the correct dependencies.

Curious to see what Guice/Dagger will look like with code generation, keep us posted!

-- 

Cédric

-- 

Cédric

[Sam Berlin]

The one catch with autofactory+Guice is that the things the generated factories create won't be able to participate in AOP (since they're explicitly new'd instead of created by Guice).  So it's a little like the first iteration of assistedinject.  OTOH, it's using generated code, which is nice in its own way.  So it's a trade-off of which support you need: AOP and/or listeners, or simpler code debugging.

 sam