IssueTracker

It is done on purpose: https://groups.google.com/forum/#!topic/guava-announce/Km82fZG68Sw

New release of guava will be ready soon, that will resolve that issue automatically.

For now you can exclude "com.google.guava:listenablefuture:1.0" in your gradle file:
implementation("android.arch.work:work-runtime:1.0.0-alpha09") {
    exclude group: 'com.google.guava', module: 'listenablefuture'
}

Maybe worthwhile to add this to the release notes.

This is done, right?

Actually, nope:
Execution failed for task ':app:android-base:transformClassesWithMultidexlistForDebug'.
> com.android.build.api.transform.TransformException: Error while generating the main dex list:
  Error while merging dex archives:
  Program type already present: com.google.common.util.concurrent.ListenableFuture
  Learn how to resolve the issue at https://developer.android.com/studio/build/dependencies#duplicate_classes.


I'm confused, why is this not a P1?

The actual fix is the Guava release.  That's already planned; I was only leaving this bug open so I can keep tabs on it.

The workaround in #2 prevents us from using ListenableWorker from alpha 10. Not using the workaround still results in:

Error while merging dex archives:
  Program type already present: com.google.common.util.concurrent.ListenableFuture

Can you explain why it's preventing you from using ListenableWorker?  Can't you instantiate a ListenableFuture to pass out of ListenableWorker?  Can you share a sample project demonstrating the problem?

We literally can't compile our apps. Again, this is a P1. Sample: https://github.com/SUPERCILEX/Robot-Scouter/tree/work

#8 if we exclude group: 'com.google.guava', module: 'listenablefuture'  then ListenableFuture is not available on the classpath.

Furthermore, I don't want to have to write my own implementation of ListenableFuture, and SettableFuture is scoped to the library.

#10: You should be getting ListenableFuture through the listenablefuture dependency WorkManager pulls in (that's why you'd be excluding the one in Guava in the first place).  It's strange that you aren't seeing this; I'll look into this tomorrow.  You don't have to use your own implementation - you can use the one available in androidx.concurret.concurrent-futures (see the release notes right below the ones for WorkManager alpha 10).

I tried that as well (using concurrent-futures) but got the same error, both with excluding the guava ones and without.

Error while merging dex archives:
  Program type already present: com.google.common.util.concurrent.ListenableFuture

To be clear, I've tried all of the following:

// doesn't work because ListenableFuture can't be found
implementation(android.arch.work:work-runtime-ktx:1.0.0-alpha10) {
    exclude group: 'com.google.guava', module: 'listenablefuture'
}

// doesn't work because SettableFuture is scoped library use only
implementation 'android.arch.work:work-runtime-ktx:1.0.0-alpha10'

// doesn't work because of Program type already present: com.google.common.util.concurrent.ListenableFuture
implementation(android.arch.work:work-runtime-ktx:1.0.0-alpha10) {
    exclude group: 'com.google.guava', module: 'listenablefuture'
}

implementation 'androidx.concurrent:concurrent-futures:1.0.0-alpha02'

// doesn't work because ListenableFuture can't be found
implementation('android.arch.work:work-runtime-ktx:1.0.0-alpha10') {
    exclude group: 'com.google.guava', module: 'listenablefuture'
}

implementation('androidx.concurrent:concurrent-futures:1.0.0-alpha02') {
    exclude group: 'com.google.guava', module: 'listenablefuture'
}

// doesn't work because of Program type already present: com.google.common.util.concurrent.ListenableFuture
implementation('android.arch.work:work-runtime-ktx:1.0.0-alpha10') {
    exclude group: 'com.google.guava', module: 'listenablefuture'
}

implementation('androidx.concurrent:concurrent-futures:1.0.0-alpha02')  {
    exclude group: 'com.google.guava', module: 'listenablefuture'
}

implementation 'com.google.guava:listenablefuture:1.0'

// doesn't work because of Program type already present: com.google.common.util.concurrent.ListenableFuture
implementation('android.arch.work:work-runtime-ktx:1.0.0-alpha10') {
    exclude group: 'com.google.guava', module: 'listenablefuture'
}

implementation('androidx.concurrent:concurrent-futures:1.0.0-alpha02')  {
    exclude group: 'com.google.guava', module: 'listenablefuture'
}

api 'com.google.guava:listenablefuture:1.0'

Note that this holds true if I use the regular work dependency instead of the ktx one.

The project in #9 compiles fine with the excludes. I had to change library/core-data/build.gradle.kts:

    implementation(Config.Libs.Jetpack.work) {
        exclude("com.google.guava", "listenablefuture")
    }
    implementation(Config.Libs.Jetpack.workFirebase) {
        exclude("com.google.guava", "listenablefuture")
    }

Do you have another project that still doesn't work with those excludes?

I have a bunch of play services, androidx, and Firebase dependencies in my app. I can never get the Gradle or AS dependency tree to work correctly, so I have no idea if any of them are using ListenableFuture. Is there any list of libraries that depend on it somewhere?

The best way to do that is to look at all your dependencies and look at who might be pulling in Guava.

/gradlew app:dependencies will help.

So did #15 solve the issue for you?

I ran a gradle scan, and nothing in my project is using listenablefuture besides for work-runtime and concurrent-futures. Also, nothing else is using concurrent-futures. grpc is using guava, but not listenablefuture.

Guava uses listenablefuture.

On Fri, Oct 19, 2018, 1:27 AM <buganizer-system@google.com> wrote:

OK so the only thing using grpc in my app is Firestore, so if I declare Firestore as:

implementation(deps.firestore) {
    transitive = false
}

and the work related dependencies as:

implementation('android.arch.work:work-runtime-ktx:1.0.0-alpha10') {
    exclude group: 'com.google.guava', module: 'listenablefuture'
}

implementation 'androidx.concurrent:concurrent-futures:1.0.0-alpha02'

Then I can build. Unfortunately Firestore doesn't like it if it doesn't have any of its transitive dependencies, and so it crashes immediately.

I tried manually including all the dependencies for Firestore, and excluding the grpc dependencies on guava, and then manually depending on guave while excluding listenablefuture, but besides for that being ridiculous, it didn't work.

So at this point, I'm not sure what your question is anymore or what you're trying to accomplish, but it seems like well outside the scope of this bug.  I see that Guava released v27.0 yesterday, where they have split the listenablefuture dependency, which was what we were waiting on to close this bug.  Given all this, I'll shut this one down.  If there are specific WorkManager issues that are not resolved, please let us know.

Filed under https://issuetracker.google.com/issues/117976872

Same problem with listenablefuture is happening with "com.google.firebase:firebase-inappmessaging-display:17.0.3". As soon as I add this library, I can't build the app anymore.

Please use the above mentioned workaround.

Your firebase library dependency is probably bringing in Guava as a transitive dependency. You need to exclude that.

May I know, is there any side effect of doing

    def work_version = "1.0.0-beta01"
    implementation ("android.arch.work:work-runtime:$work_version") {
        exclude group: 'com.google.guava', module: 'listenablefuture'
    }

Will it pick a wrong version of listenablefuture library from other dependencies?

delete

Guava v27 didn't "split" interface declaration into separate artifact.

```
+--- com.google.guava:guava:27.0.1-android
|    +--- com.google.guava:failureaccess:1.0.1
|    +--- com.google.guava:listenablefuture:9999.0-empty-to-avoid-conflict-with-guava
|    +--- com.google.code.findbugs:jsr305:3.0.2 -> 2.0.1
|    +--- org.checkerframework:checker-compat-qual:2.5.2 -> 2.3.0
|    +--- com.google.errorprone:error_prone_annotations:2.2.0
|    +--- com.google.j2objc:j2objc-annotations:1.1
|    \--- org.codehaus.mojo:animal-sniffer-annotations:1.17
```

You can see that `com.google.guava:listenablefuture:9999.0-empty-to-avoid-conflict-with-guava` doesn't contain declaration. It is still in the main guava jar. Which means that we are back into forcing every workmanager user to deal with "Program type already present: com.google.common.util.concurrent.ListenableFuture" build errors.

Databinding depends on guava. Espresso depends on guava. Android tests depends on main test sources. So it becomes the main use case where majority of devs have to figure out how to exclude duplication from one jar or another. Why?

#28: I'm not sure what you mean.  Please see the changelog here: https://github.com/google/guava/releases/tag/v27.0 and the Guava announcement here: https://groups.google.com/forum/#!topic/guava-announce/Km82fZG68Sw

Was having listenablefuture to be jarjared for workmanager considered as an option?

As stated at Guava announcement `listenablefuture` and `guava` are mutually exclusive dependencies. Having both `com.google.guava:listenablefuture:1.0` and `com.google.guava:guava:27.0.1-android` on the same classpath results in compilation error due to duplicate interface declaration. On android we want to have listenable future on assembling apk classpath but really everything else depends on guava. Example:

* `implementation "android.arch.work:work-runtime:1.0.0-beta01"` depends on listenablefuture:1.0`
* `testImplementation "com.google.truth:truth:0.42" depends on full guava.

But testImplementation (and androidTestImplementation) extends implementation and it is the same classpath so we have to go for gradle code to be able to resolve it. Similar to this:

```
subprojects { subProject ->
    subProject.configurations.all { configuration ->

        def guavaFound = false // Note: state depends on dependencies order - we expect guava to be iterated *before* listenablefuture.
        resolutionStrategy.sortArtifacts(ResolutionStrategy.SortOrder.CONSUMER_FIRST)

        resolutionStrategy {
            eachDependency { DependencyResolveDetails details ->
                switch (details.requested.group) {
                    case "com.google.guava":
                        if (details.requested.name == "guava") { // guava has several artifacts under same group after v27
                            guavaFound = true
                            if (details.requested.version.endsWith("-jre")) {
                                details.useVersion "27.0.1-jre"
                            } else if (details.requested.version.endsWith("-android")) {
                                details.useVersion "27.0.1-android"
                            } else {
                                // Guava versions before 23.1 didn't have '-jre' postfix
                                details.useVersion "27.0.1-jre"
                            }
                        } else if (details.requested.name == "listenablefuture") { // https://issuetracker.google.com/issues/116154359
                            if (guavaFound) {
                                // Configurations with full guava jar should exclude listenablefuture.
                                details.useVersion "9999.0-empty-to-avoid-conflict-with-guava"
                            } else {
                                details.useVersion "1.0"
                            }
                        }
                        break
                }
            }
        }
    }
}
```

As you can see we already have conflict for guava itself, since databinding, butterknife, lint, checkstyle, ktlint, truth are using jre artifact, but android specific libraries android version. Now we have to deal with 9999 vs 1.0 listenablefuture as well. Idea was that gradle automatically resolve 1.0 or 9999.0 but I don't think that automatic resolution is suitable for majority of android users, since we need to help gradle to determine android or jre artifacts manually.

Correction: looks like espresso doesn't declare guava as dependency from v3 and fully jarjars it now.

Everything works fine if you have a project with guava v27 and the newest version of WorkManager.  I just tried it out in a new project.

This builds just fine:

dependencies {
    implementation 'android.arch.work:work-runtime:1.0.0-beta01'
    implementation 'com.google.guava:guava:27.0.1-android'
}

If you have a specific problem, file a new bug with your gradle file.  But as long as your project's dependencies are pulling the newest version of Guava, you will not see this error.

How does one get the good people over at the Google Places API to include the newest Guava version?  Below dependency scan shows: |    +--- com.google.guava:guava:23.5-android

+--- com.google.android.libraries.places:places:1.0.0
|    +--- com.android.volley:volley:1.1.1
|    +--- com.github.bumptech.glide:glide:4.3.1
|    |    +--- com.github.bumptech.glide:gifdecoder:4.3.1
|    |    |    \--- androidx.annotation:annotation:1.0.0 -> 1.1.0-alpha01
|    |    +--- com.github.bumptech.glide:disklrucache:4.3.1
|    |    \--- com.github.bumptech.glide:annotations:4.3.1
|    +--- com.google.android.gms:play-services-base:16.1.0 (*)
|    +--- com.google.android.gms:play-services-basement:16.2.0 (*)
|    +--- com.google.android.gms:play-services-clearcut:16.0.0
|    |    +--- com.google.android.gms:play-services-base:16.0.1 -> 16.1.0 (*)
|    |    +--- com.google.android.gms:play-services-basement:16.0.1 -> 16.2.0 (*)
|    |    +--- com.google.android.gms:play-services-phenotype:16.0.0
|    |    |    +--- com.google.android.gms:play-services-base:16.0.1 -> 16.1.0 (*)
|    |    |    +--- com.google.android.gms:play-services-basement:16.0.1 -> 16.2.0 (*)
|    |    |    \--- com.google.android.gms:play-services-tasks:16.0.1 (*)
|    |    \--- com.google.android.gms:play-services-tasks:16.0.1 (*)
|    +--- com.google.android.gms:play-services-location:16.0.0 (*)
|    +--- com.google.android.gms:play-services-maps:16.0.0 -> 16.1.0
|    |    +--- com.google.android.gms:play-services-base:16.0.1 -> 16.1.0 (*)
|    |    \--- com.google.android.gms:play-services-basement:16.0.1 -> 16.2.0 (*)
|    +--- com.google.android.gms:play-services-tasks:16.0.1 (*)
|    +--- com.google.auto.value:auto-value-annotations:1.6.2
|    +--- com.google.code.gson:gson:2.8.5
|    +--- com.google.guava:guava:23.5-android
|    |    +--- com.google.code.findbugs:jsr305:1.3.9
|    |    +--- org.checkerframework:checker-qual:2.0.0
|    |    +--- com.google.errorprone:error_prone_annotations:2.0.18
|    |    +--- com.google.j2objc:j2objc-annotations:1.1
|    |    \--- org.codehaus.mojo:animal-sniffer-annotations:1.14
|    +--- androidx.appcompat:appcompat:1.0.0 -> 1.1.0-alpha02 (*)
|    +--- androidx.cardview:cardview:1.0.0
|    |    \--- androidx.annotation:annotation:1.0.0 -> 1.1.0-alpha01
|    +--- androidx.recyclerview:recyclerview:1.0.0 (*)
|    \--- androidx.legacy:legacy-support-v4:1.0.0 (*)

For def work_version = "1.0.0-rc02" , using implementation 'com.google.guava:guava:27.0.1-android' does solve the issue. However, will this increase APK size unnecessary, as in our application code, we do not call any guava library code explicitly.

This won't increase your apk size - you're already pulling in Guava somehow, which is why you need to make this change in the first place.