Dagger: 2.25.3 requires com.google.common.collect.ImmutableList

[tmtrademarked]

It looks like Dagger 2.25.3 has introduced a dependency on something from google.common.collect in a breaking fashion. In my app, I upgraded only from Dagger 2.25.2 to Dagger 2.25.3, and started seeing the following compilation failure:

e: [kapt] An exception occurred: java.lang.NoSuchMethodError: com.google.common.collect.ImmutableList.toImmutableList()Ljava/util/stream/Collector;
        at dagger.internal.codegen.binding.InjectionAnnotations.getQualifiers(InjectionAnnotations.java:95)
        at dagger.internal.codegen.validation.DependencyRequestValidator.checkQualifiers(DependencyRequestValidator.java:90)
        at dagger.internal.codegen.validation.DependencyRequestValidator.validateDependencyRequest(DependencyRequestValidator.java:68)
        at dagger.internal.codegen.validation.InjectValidator.validateDependencyRequest(InjectValidator.java:244)
        at dagger.internal.codegen.validation.InjectValidator.validateField(InjectValidator.java:205)
        at dagger.internal.codegen.validation.InjectValidator.validateMembersInjectionType(InjectValidator.java:256)
        at dagger.internal.codegen.validation.InjectBindingRegistryImpl.tryRegisterMembersInjectedType(InjectBindingRegistryImpl.java:280)
        at dagger.internal.codegen.validation.InjectBindingRegistryImpl.tryRegisterMembersInjectedType(InjectBindingRegistryImpl.java:264)
        at dagger.internal.codegen.InjectProcessingStep$1.visitVariableAsField(InjectProcessingStep.java:54)
        at dagger.internal.codegen.InjectProcessingStep$1.visitVariableAsField(InjectProcessingStep.java:44)
        at javax.lang.model.util.ElementKindVisitor6.visitVariable(ElementKindVisitor6.java:229)
        at com.sun.tools.javac.code.Symbol$VarSymbol.accept(Symbol.java:1237)
        at dagger.internal.codegen.InjectProcessingStep.process(InjectProcessingStep.java:76)
        at dagger.internal.codegen.validation.TypeCheckingProcessingStep.lambda$process$0(TypeCheckingProcessingStep.java:51)
        at java.util.Map.forEach(Map.java:630)
        at dagger.internal.codegen.validation.TypeCheckingProcessingStep.process(TypeCheckingProcessingStep.java:48)
        at dagger.internal.codegen.validation.TypeCheckingProcessingStep.process(TypeCheckingProcessingStep.java:34)
        at dagger.internal.codegen.statistics.DaggerStatisticsCollectingProcessingStep.process(DaggerStatisticsCollectingProcessingStep.java:52)
        at dagger.shaded.auto.common.BasicAnnotationProcessor.process(BasicAnnotationProcessor.java:330)
        at dagger.shaded.auto.common.BasicAnnotationProcessor.process(BasicAnnotationProcessor.java:181)
        at org.jetbrains.kotlin.kapt3.base.incremental.IncrementalProcessor.process(incrementalProcessors.kt)
        at org.jetbrains.kotlin.kapt3.base.ProcessorWrapper.process(annotationProcessing.kt:147)
        at com.sun.tools.javac.processing.JavacProcessingEnvironment.callProcessor(JavacProcessingEnvironment.java:802)
        at com.sun.tools.javac.processing.JavacProcessingEnvironment.discoverAndRunProcs(JavacProcessingEnvironment.java:713)
        at com.sun.tools.javac.processing.JavacProcessingEnvironment.access$1800(JavacProcessingEnvironment.java:91)
        at com.sun.tools.javac.processing.JavacProcessingEnvironment$Round.run(JavacProcessingEnvironment.java:1043)
        at com.sun.tools.javac.processing.JavacProcessingEnvironment.doProcessing(JavacProcessingEnvironment.java:1184)
        at com.sun.tools.javac.main.JavaCompiler.processAnnotations(JavaCompiler.java:1170)
        at com.sun.tools.javac.main.JavaCompiler.processAnnotations(JavaCompiler.java:1068)
        at org.jetbrains.kotlin.kapt3.base.AnnotationProcessingKt.doAnnotationProcessing(annotationProcessing.kt:79)
        at org.jetbrains.kotlin.kapt3.base.AnnotationProcessingKt.doAnnotationProcessing$default(annotationProcessing.kt:35)
        at org.jetbrains.kotlin.kapt3.AbstractKapt3Extension.runAnnotationProcessing(Kapt3Extension.kt:224)
        at org.jetbrains.kotlin.kapt3.AbstractKapt3Extension.analysisCompleted(Kapt3Extension.kt:187)
        at org.jetbrains.kotlin.kapt3.ClasspathBasedKapt3Extension.analysisCompleted(Kapt3Extension.kt:98)
        at org.jetbrains.kotlin.cli.jvm.compiler.TopDownAnalyzerFacadeForJVM$analyzeFilesWithJavaIntegration$2.invoke(TopDownAnalyzerFacadeForJVM.kt:97)
        at org.jetbrains.kotlin.cli.jvm.compiler.TopDownAnalyzerFacadeForJVM.analyzeFilesWithJavaIntegration(TopDownAnalyzerFacadeForJVM.kt:107)
        at org.jetbrains.kotlin.cli.jvm.compiler.TopDownAnalyzerFacadeForJVM.analyzeFilesWithJavaIntegration$default(TopDownAnalyzerFacadeForJVM.kt:82)
        at org.jetbrains.kotlin.cli.jvm.compiler.KotlinToJVMBytecodeCompiler$analyze$1.invoke(KotlinToJVMBytecodeCompiler.kt:557)
        at org.jetbrains.kotlin.cli.jvm.compiler.KotlinToJVMBytecodeCompiler$analyze$1.invoke(KotlinToJVMBytecodeCompiler.kt:82)
        at org.jetbrains.kotlin.cli.common.messages.AnalyzerWithCompilerReport.analyzeAndReport(AnalyzerWithCompilerReport.kt:107)
        at org.jetbrains.kotlin.cli.jvm.compiler.KotlinToJVMBytecodeCompiler.analyze(KotlinToJVMBytecodeCompiler.kt:548)
        at org.jetbrains.kotlin.cli.jvm.compiler.KotlinToJVMBytecodeCompiler.compileModules$cli(KotlinToJVMBytecodeCompiler.kt:177)
        at org.jetbrains.kotlin.cli.jvm.K2JVMCompiler.doExecute(K2JVMCompiler.kt:165)
        at org.jetbrains.kotlin.cli.jvm.K2JVMCompiler.doExecute(K2JVMCompiler.kt:55)
        at org.jetbrains.kotlin.cli.common.CLICompiler.execImpl(CLICompiler.kt:84)
        at org.jetbrains.kotlin.cli.common.CLICompiler.execImpl(CLICompiler.kt:42)
        at org.jetbrains.kotlin.cli.common.CLITool.exec(CLITool.kt:104)
        at org.jetbrains.kotlin.daemon.CompileServiceImpl.compile(CompileServiceImpl.kt:1558)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:498)
        at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:357)
        at sun.rmi.transport.Transport$1.run(Transport.java:200)
        at sun.rmi.transport.Transport$1.run(Transport.java:197)
        at java.security.AccessController.doPrivileged(Native Method)
        at sun.rmi.transport.Transport.serviceCall(Transport.java:196)
        at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:573)
        at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:834)
        at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:688)
        at java.security.AccessController.doPrivileged(Native Method)
        at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:687)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
        at java.lang.Thread.run(Thread.java:748)

Is this intentional? If so, is there a suggested change that developers are supposed to make to their build setup in order to bring these required classes in correctly?

[danysantiago]

Hmm, toImmutableList() has been available since Guava 21 and Dagger is depending on 27.1. Do you have any Guava conflict resolution in your setup? As a transitive dependency which version of Guava is it being pulled in your project? In Gradle you can find some of this information via a command like gradlew app:dependencies.

[tmtrademarked]

Hmm - we don't pull Guava into our project directly at all, but we also don't have any specific conflict resolution in our build. In our kapt output from dependencies, I can see that dagger-compiler seems to be getting guava 28.1-android, which seems like it should be good enough?

+--- com.google.dagger:dagger-compiler:2.25.3
|    +--- com.google.dagger:dagger:2.25.3
|    |    \--- javax.inject:javax.inject:1
|    +--- com.google.dagger:dagger-producers:2.25.3
|    |    +--- com.google.dagger:dagger:2.25.3 (*)
|    |    +--- com.google.guava:failureaccess:1.0.1
|    |    +--- com.google.guava:guava:27.1-jre -> 28.1-android (*)
|    |    +--- javax.inject:javax.inject:1
|    |    \--- org.checkerframework:checker-compat-qual:2.5.3 -> 2.5.5

Is there something about using the Android variant of guava that could cause a problem? It seems very weird that this was introduced in a very small set of seemingly innocent changes.

In case it's relevant, we are currently compiling against SDK 28. Is it possible that somehow, there's something about the switch of dagger to compile against 29 that causes this?

[tmtrademarked]

Aha - that does in fact appear to be the problem. I should have been a little more precise in my previous statement: we do directly include guava in an annotation processor, which is where Dagger is getting this version of Guava pulled in. Switching our dependency on guava from com.google.guava:guava:28.1-android to com.google.guava:guava:28.1-jre appears to have fixed the compilation issue. But that seems... less than ideal to have to do.

Any thoughts about whether this the intended state here? On our end, we could certainly fix this just by using the jre version of guava in our annotation processor toolchain and including the android version in the app if that becomes necessary longer term. But I wonder if other developers could end up being burned by something like this going forward.

[danysantiago]

Using the -android variant for the dagger-compiler is indeed an issue, because the -android variant is meant to target the JDK 7 runtime equivalent in Android and the missing API is for Java 8 where streams was introduced so it gets stripped out of that variant. Since annotation processors run in the host machine that is compiling, using the -jre variant would be correct for the processor classpath and then the -android variant for your app. However, we know this can be easy to miss so in Dagger we have internal equivalent APIs so if someone does bring their -android variant this doesn't happen but looks like we missed it so we do have to fix it.

[chemouna]

We're encountering the same issue as well, any update on when it may be fixed ?
Thanks