I will give a second answer, but you really should have opened a second question...

First of all: you rarely ever implement a provider. Guice will automagically create them for you. To explain this: When I bind a class Foo as follows:

bind(Foo.class).to(FooImpl.class)

You can inject in you class either Foo or Provider<Foo>. Guice will create the provider for you.

The reason why you should not implement the provider yourself, is that AOP is not working on instances that where created with a call to new. When you use a debugger to look at the run time instance of an injected object which uses interceptors you will notice that Guice created a subclass on the fly allowing it to intercept the method calls.

To your example:

The main problem is, that ProductModel should not be injected. It is a domain object and holds data. These kind of objects should not be created/managed by DI. Instead you code is responsible to create/retrieve and store the model from its persistent state. The presenter has now two different dependencies. One is the model which lives outside of DI and one is the view which can be handled by DI (just as a side note: if you need the same instance of the view to be injected on more than one object you must place it in a (custom-) scope. But answers to scopes deserve a new question).

To solve the above dilemma Guice offers assisted injection. This allows you to write a code like to following:

public class ProductPresenter {

    public interface Factory {
        createPresenter(ProductModel model);
    }

    @Inject
    ProductPresenter(@Assisted ProductModel model, ProductView view) {
        this.model = model;
        this.view = view;
    }
}

you then bind the factory as follows:

install(new FactoryModuleBuilder().build(ProductPresenter.Factory.class));

Guice will create an implementation of the ProductPresenter.Factory interface on the fly. The created instance will get the arguments passed to the factory method put into the constructor. Also AOP is working on the created instance. This way you can mix DI with non DI objects.

It's a bad practice to inject an injector, or otherwise pass it round in some way that makes it accessible to code outside of startup. That confuses what's going on; do that and when something goes wrong, you have to debug your code via debugging the dependency injection state.

The right, static, way to do things is to inject either a hand-written factory object, or a Provider. The difference being that the latter will set the created object up as a DI object, i.e. processing @Inject annotations.

Internally, the implementation of a provider presumably uses the injector, but as it is only doing it for a single thing it is easier to reason about and debug. And if you draw the dependency graph for your system, because Provider is Provider<X>, you should get the actual graph of logical dependencies with your class depending on X. Not a mess with a 'magic happens' node at a single injector used for everything.

Note that when you do this, you don't need to supply a binding or implementation for the Provider; it has built-in default.

Ok, those are many questions you have and I guess some of the points can be approached in more than one way.

Creating the injector is not cheap. Guice will do some analysis to detect errors as well as create all singletons. So you should create the injector at startup.

I usually have a single injector for my application.

Regarding your question 1.:

Yes the injector can be injected. But I see it as a bad practice. Reason for this is that calls to injector.getInstance() and injector.injectMembers() make it hard to reason about the dependencies of a class.

• if you need to create more than one instance or you need to control the time when an instance is created inject a Provider instead of X.
• if the object you want to create needs both runtime parameters and dependencies use assisted inject.
• for many kinds of objects (like DTO, POJO and alike) its absolutely ok to create them by calling new or a conventional factory.

In this sense the injector is implicitly available to any instance created by Guice this includes the API user.

And finally AOP. Aspects are a powerful feature but also can hide some of the business logic I suggest to use them only for very repetitive tasks which all developers know well.

Also take into account that aspects only work on:

• instances created by Guice
• non private, non static, non private methods

Finally, Guice won't inform you if you add an annotation to either of the above. Your aspect will silently be ignored