Guava 27.0.1 and 27.1 have transitive dependencies on failureaccess and listenablefuture

[rhuffman]

My build using either 27.0.1 or 27.1 have transitive dependencies on failureaccess and listenablefuture. This is the output of my gradle dependencies task:

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

I understand from Issue #3302 that these dependencies are not actually use by guava-27.*-jre, so they should not be required in my build. I expect I can exclude them, but I should not have to.

[rhuffman]

I was wrong: I cannot exclude those dependencies. Doing so I run into this compilation error in my build:

StreamCache.java:177: error: cannot access InternalFutureFailureAccess
private final SettableFuture future = SettableFuture.create();
^
class file for com.google.common.util.concurrent.internal.InternalFutureFailureAccess not found

AbstractFuture extends InternalFutureFailureAccess, which is not present in guava-27.1-jre.

[rhuffman]

I was hasty in posting this. I misunderstood issue #3302 and mistakenly thought these dependencies were not supposed to be necessary. Now I see that we do in fact need these dependencies, but there is an on-going discussion about whether or not that was the correct decision.

For my part, I feel it was not. It would be much better for my projects (which includes multiple server side libraries) if Guava were a single artifact. I am hoping the discussion in issue #3320 lands on the side of going back to a single jar in version 28.