spam spam - 1 year ago 164
Java Question

Why use/develop Guice, when You have Spring and Dagger?

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.

Answer Source

It's important to realize that Dagger was created after Guice, by one of Guice's creators ("Crazy Bob" Lee) after his move to Square:

  • Spring was originally released in October 2002.
  • Google originally publicly released Guice in March 2007.
  • JSR-330 formalized javax.inject annotations in October 2009, with heavy input from Google (Bob Lee), Spring, and other industry players.
  • 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 ago, 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. 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 different VM makes 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, but leave it up to the integrations and performance you need alongside your team's technical judgment.