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()...build()) 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 on code formatting

Using -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 issues.

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 @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.