Compiler Options

fastInit mode

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.create() or DaggerFooComponent.builder() scales with the number of bindings in the component. In “fastInit” mode, it doesn’t. There are tradeoffs, however. Normally, each 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 scoped instances.

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 Dagger @Component: -Adagger.fastInit=enabled.

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: -Adagger.formatGeneratedSource=disabled.

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 @Component or @ProductionComponent. However, if you pass -Adagger.fullBindingGraphValidation=ERROR or -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 component.)

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.