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

Solution 1:

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

• Spring was originally released in October 2002.
• Google originally released Guice publicly 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 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.