86

To my knowledge, Dagger does generate code, while Guice and Spring rely on runtime processing, thus Dagger works faster, but requires more work on programmer side. Because of performance edge it's good for mobile (Android) development.

However, when we are left with Guice and Spring, the latter has lots of integrations. What's the point of developing/using Guice, if we can use Spring Framework (that does basically same thing, but offers ex. easier database access)?

Isn't Google trying to reinvent wheel by creating their own DI tool, instead of using (and possibly contributing to) Spring Framework?

I am looking for decision tree, that guides through choosing DI tool.

spam
  • 1,853
  • 2
  • 13
  • 33
  • 2
    SO is not about recommending/comparing software products. I think your question is thus really offtopic here. – GhostCat Sep 25 '16 at 15:54
  • Spring is a big, giant, massive collection is libraries and utilities. The DI framework is only a small part of it. Guice is lightweight and only a DI framework. Furthermore, GWT (for example) cannot use Spring because it is compiled to JavaScript. One could ask why Spring exists being as it is reinventing [CDI](https://docs.oracle.com/javaee/6/tutorial/doc/giwhl.html). – Boris the Spider Sep 25 '16 at 15:57
  • 3
    @GhostCat ok, so where should I ask about it? – spam Sep 25 '16 at 16:21
  • @BoristheSpider I am using spring with vaadin (that uses gwt) and it works fine. what makes spring heavyweight compared to guice in terms of DI? – spam Sep 25 '16 at 16:21
  • You are using Spring on the _server side_ I assume. Not in the client code. As for your second question; I leave that as an exercise to you to do some research. – Boris the Spider Sep 25 '16 at 16:22
  • I'm voting to close this question as off-topic because it isn't on scope, duh – Olivier Grégoire Sep 25 '16 at 17:15
  • Not may question, but why down vote ?! – Alireza Fattahi Mar 01 '17 at 11:05
  • https://www.youtube.com/watch?v=oK_XtfXPkqw – k4dima Jun 03 '18 at 13:02

1 Answers1

234

It's important to acknowledge that Dagger was created after Guice, by one of Guice's creators ("Crazy Bob" Lee) who had moved to Square:

  • Rod Johnson originally released Spring in October 2002 with his book Expert One-on-One J2EE Design and Development; Spring was then released publicly on the Apache license in June 2003 and as v1.0 in March 2004.
  • Google originally released Guice publicly in March 2007.
  • JSR-330 formalized javax.inject annotations in October 2009, as submitted by Google (Bob Lee) and SpringSource (Rod Johnson), with other industry collaborators on its Expert Group.
  • Square originally released Dagger 1 publicly in May 2013.
  • Google originally released Dagger 2 publicly in April 2015.
  • Square marked Dagger 1 as deprecated 10 days before this question was asked, on September 15, 2016.

In that sense, the continued curation of Guice isn't "reinventing the wheel" so much as maintenance on a long-running and widely-consumed software package that thoroughly predates any version of Dagger. You might consider Dagger to be a spiritual successor to Guice, but one that only offers an optimized subset of Guice's functionality.

To list and amend to the differences you have above:

  • Spring is a relatively-heavyweight framework with a lot of integrations, an XML configuration language, and runtime/reflective bindings. Applications already using Spring can use Spring's dependency injection framework with very little extra work.
  • Guice is a relatively-lightweight framework with fewer integrations, Java instance configuration, and runtime/reflective bindings. With the use of Java bindings, you get compile-time type checking and IDE autocomplete integration.
  • Dagger is a very lightweight framework with very few integrations, Java interface/annotation configuration, and compile-time code-generated bindings. The code generation aspect makes Dagger very performant overall and particularly in resource-limited and mobile environments. (Android's VMs differ from server JREs in ways that make reflection especially slow, so Dagger is especially useful here.)
  • All three of the above frameworks support JSR-330, so a well-crafted library or application can be mostly agnostic to the DI container used.

Beyond that, keep an eye out for maintenance/deprecation patterns and policies among any framework you use. Based on your team's knowledge and experience, your need for reflection or runtime configuration, and your need for integrations and runtime performance, you'll probably see one of the above stand out. That said, there are also other frameworks out there, so keep an eye open for new options and forks of the above as well.

Jeff Bowman
  • 90,959
  • 16
  • 217
  • 251
  • Much thanks for You answer, it opened my eyes on many things. Indeed, in this case calling Guice reinventing is major mistake. If all those 3 frameworks implement same standard, is it possible to ex. use Dagger lightweight DI instead of Spring's, but at the same time, keep Spring's integrations (like Spring Data)? – spam Sep 25 '16 at 17:21
  • 3
    @spam Glad you liked the answer! I haven't looked into Spring Data, but I don't think you can necessarily assume that you can use integrations from one framework on another. Even though they equivalently handle DI as defined by JSR-330, some frameworks have internal data structures or reflection/introspection that are unavailable elsewhere. You may need to weigh the use of Spring vs Dagger in the integrations that they make available. – Jeff Bowman Sep 25 '16 at 17:36
  • 53
    This is a good answer - you're turned a question that could have been opinion based into a valuable summary of the major players in 3rd party DI frameworks. +1! – Boris the Spider Sep 25 '16 at 17:38
  • As I see in github of Guice, they are using reflections - how is it lightweight? Isn't Spring doing same thing (talking about DI only now)? – spam Sep 25 '16 at 18:55
  • @spam For my definition of heavyweight/lightweight above, I'm talking about the whole framework moreso than the IoC container portion. – Jeff Bowman Sep 25 '16 at 18:58
  • 1
    But Spring Framework (without Spring subprojects) does just little more than DI like Guice. Are You able to suggest few use cases, where Guice would be good choice and Spring Framework - not? – spam Sep 25 '16 at 19:48
  • Can you please explain why spring framework is light weight? – explorer Jun 25 '21 at 14:58