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.
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
^
class file for com.google.common.util.concurrent.internal.InternalFutureFailureAccess not found
AbstractFuture extends InternalFutureFailureAccess, which is not present in guava-27.1-jre.
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.
Most helpful comment
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.