Guava: Guava 27.0.1 and 27.1 have transitive dependencies on failureaccess and listenablefuture

Created on 8 Apr 2019  路  2Comments  路  Source: google/guava

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.

status=obsolete

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.

All 2 comments

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.

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.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

philgebhardt picture philgebhardt  路  3Comments

cpovirk picture cpovirk  路  5Comments

gissuebot picture gissuebot  路  5Comments

epkugelmass picture epkugelmass  路  4Comments

Bocete picture Bocete  路  3Comments