Dagger: A Fast Dependency Injector for Android and Java

so why use that over guice for instance ?

This talk demonstrates that DI frameworks actually foster bad design. Creating a monolithic object graph on which everything depends isn't desirable for larger applications. Instead of making injection of static code into modules as easy as possible better seek to create independent modules that can be (re-)used in different contexts. I've come to the conclusion that DI is an Anti-pattern that should be avoided.

Your title is a bit misleading. DI is not an anti-pattern, far from it, but using magic DI containers certainly is, including, it would appear, Dagger.

What's worse is, there's no point to this hand-waving. It buys you absolutely nothing, and it costs you code clarity and pollutes your classes with annotation dependencies.

Let's take the DripCoffeeModule and remove the annotations. Voila, you just have a perfectly useable class for resolving DI, but without the magic:

class CoffeeApp {
	public static void main(String[] args) {
		DripCoffeeModule mod = new DripCoffeeModule();
		Heater heater = mod.provideHeater();
		Pump pump = mod.providePump(new Thermosiphon(heater));
		CoffeeMaker cm = new CoffeeMaker(heater, pump);
		coffeeMaker.brew();
	}
}

Nils, your code is much easier because your program is much simpler. But few applications consist of single method where all dependencies can be wired up. Let's say you have 20 different places in your application where you need to use Pump. Are you going to new up Thermosiphon in twenty different places? In that case, you just surrendered loose coupling. Maintaining loose coupling in large, multi-layered applications is the purpose of IoC containers.

I don't think so. I used Spring a short while back in 2004 and I quickly realized that coding in XML was entirely unnecessary. You can do the same wiring in real code. I have yet to see a DI container that adds value beyond the cost of its footprint and learning curve.

I'm not sure why you bring up XML--of course it's unnecessary. Any IoC framework worth its salt nowadays--including Dagger--allow you to do all the wiring in code, and that's the preferred method for most people. Implementing dependency injection yourself has always been an option, but you are writing a lot of boilerplate code, in addition to forgoing extra benefits that many IoC containers give you, such as named registrations, scope control, etc, which I use a great deal.

I guess my point is that I have yet to see a DI container that adds value, XML or annotations regardless. DI is pretty straight forward and wiring up all that magic is not providing the proper cost/benefit result. IMO of course.

The value is that the DI container gets rid of the factory boilerplate code which you have to write by hand. Other than that, I agree with your points.