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 off code formatting
By default, Dagger formats all of the code it generates with
google-java-format. This makes
the generated code readable, which is useful for debugging in an IDE or having
useful line numbers in stack traces. Formatting may however incur a noticeable
cost at compilation time, so Dagger provides a flag to disable this behavior:
It is strongly recommended to disable formatting only during development, not in production code or continuous integration tests. Otherwise stack traces may not be easy to interpret, since the unformatted source may not be as readable.
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.
Gradle incremental compilation
Dagger has conditional support for Gradle’s incremental annotation processing.
To enable this in your build, pass
-Adagger.gradle.incremental as an option to
javac. Please help us validate (and file bugs if you see weirdness!) so that
we can enable this broadly.
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.