You can choose to generate your Dagger
@Components in a mode that
prioritizes fast initialization. Normally, the number of classes loaded when
initializing a component (i.e., when calling
DaggerFooComponent.builder()...build()) scales with the number of bindings in
the component. In “fastInit” mode, it doesn’t. There are tradeoffs, however.
Provider you inject holds a reference to providers
of all its transitive dependencies; in fastInit mode, each
Provider holds a reference to the entire component, including all
You should evaluate this tradeoff for your application when choosing to build in fastInit mode. Take care to measure your application’s startup time with and without fastInit mode to see how much benefit it has for your users. (Please let us know whether it’s working for you!) In general, for environments like Android where Dagger initialization is often on the user’s critical path and where class loading is expensive, consider using fastInit mode.
To enable fastInit mode, pass the following option to javac when building your
Turning on code formatting
-Adagger.formatGeneratedSource=enabled will cause Dagger’s generated
sources to be formatted according to google-java-format. However, by default
this option is disabled because it can lead to noticable build performance
In most cases, the default formatting should be very readable, but you might prefer to enable this option in production code or continuous integration tests to make stack traces easier to interpret (since the unformatted source may squeeze more things on the same line).
Note: Formatting of a 143k line file generated by Dagger (one of the largest at Google!) took between 2.6 and 3 seconds in a benchmarking test. As with all optimizations, verify the effects on your machine/environment.
Full binding graph validation
By default, problems among the bindings in a module or subcomponent or component
don’t get reported unless they are used as part of a whole component tree rooted
at a root
@ProductionComponent. However, if you pass
-Adagger.fullBindingGraphValidation=WARNING to javac, then all the bindings
of each module, subcomponent, and component will be checked, including those
that aren’t used. Any binding graph errors, such as duplicate bindings, will be
reported at the module, subcomponent, or component. (Note that missing bindings
will not be reported for full binding graphs unless they’re also found when
analyzing the binding graph that’s actually used to generate the root
If full binding graph validation is turned on, SPI implementations
will see a
BindingGraph representing the bindings for each module, component,
and subcomponent as well.