Sourced from dagger's releases.
Dagger 2.42
What’s new in Dagger
Potentially breaking changes
As of this release, Dagger’s generated class will no longer extend the user-defined
@Componentannotated class (885b16dcf). This change was done to improve build times in certain scenarios by avoiding a known javac bottleneck. However, it may also be a breaking change for some users. For example// This will fail as of Dagger version 2.42 DaggerMyComponent component = DaggerMyComponent.create();// Do this instead: MyComponent component = DaggerMyComponent.create();
For migration purposes, we’ve added a temporary javac flag that can be used to re-enable the legacy behavior (the flag is disabled by default).
-Adagger.generatedClassExtendsComponent=ENABLEDThis flag will be removed in a future version of Dagger.
What’s new in Hilt
Bug fixes
- Fix two issues (e3d446873):
matchingFallbacksbeing ignored work with Hilt.- Hilt causing jetifier to execute twice.
- Allow Hilt view constructor to contain non-declared types. (dc76e82c0)
- Fix #3222. Generated fragment code previously would cause a Lint issue around
LayoutInflater.from(). (850fc8474)- Fix #3329 where modules in a package with non-standard capitalization could cause an error in the Hilt Gradle Plugin. (029fe5702 and 329915f5f)
Dagger 2.41
What’s New In Dagger
Potentially Breaking Changes
This release fixes a recently noticed, but long-standing bug (#3136) where Dagger’s processors may silently miss a scope/qualifier on a binding if the scope/qualifier annotation is unresolvable (i.e. it is not on the classpath).
Dagger will now prefer to fail the build if there are any unresolvable annotations present where a scope/qualifier is allowed. While Dagger does its best to avoid failing the build for non-scope/qualifier annotations, in general it’s not possible to tell if an annotation is a scope/qualifier unless its type is resolvable -- thus, Dagger may fail on non-scope/qualifier annotations as well.
If these changes break your build, we recommend first trying to fix the breakage by adding the appropriate missing dependencies to your build (in most cases the error message should tell you exactly what type is missing). Although not recommended, you can revert back to the old behavior using the compiler option-Adagger.strictSuperficialValidation=DISABLED; however, this option will be removed in a future release. If the breakage is specifically due to the validation of transitive component dependencies, you may choose to disable that validation using-Adagger.validateTransitiveComponentDependencies=DISABLED. If the breakage is specifically due toandroidx.hilt:hilt-lifecycle-viewmodelyou will need to migrate to the native Hilt API (see google/dagger#3257).This release fixes an accidental regression (introduced in Dagger version 2.39) that allowed requesting a raw
@Injectconstructor type which was previously not allowed (a61aa50c8).
We expect breakages due to this issue to be relatively rare and easy to fix -- just replace the raw type with the proper parameterized type.
... (truncated)
46fc050 2.42 releasec3f1944 Update kotlin-metadata-jvm to 4.0 which support reading metadata from upcomin...b60b8e5 Remove usages of .java(), toJavac(), and toXProcessing() which were nee...e793595 Internal Changes.d14a3d6 Manually pass in application instance when creating EarlySingletonComponent.b0aa9f1 Replace javac implementation of XProcessingEnv#isAssignable() with XProcessin...dfab36d Improve the error message for conflicting entry points.0dfbcaa [Refactor] Move CompositeBindingGraphValidator into bindinggraphvalidation pa...1a01575 Fix O(N^2) performance issue when determining declaration order.75a79c0 Update the XProcessing jar