Plans for a separate artifact containing only ListenableFuture

[Chris Povirk]

Guava users,

Some Android library developers have told us that they would like to use ListenableFuture in their APIs, but they know that a full Guava dependency would be bad for apps that don't use Proguard. To address this, we are planning to release a separate artifact that contains only ListenableFuture.

To be clear, we don't expect to carve off similar artifacts for other parts of Guava; we see ListenableFuture as a unique case.

Part of the reason that it's unique is that it is an interface that we will likely never change -- not even to add methods. This ensures that, even if an app depends on both the new artifact and the main Guava artifact, it will always see the one and only version of ListenableFuture.

We still anticipate that some users -- including users of Android Studio -- will see "duplicate class" or "duplicate entry" errors if they depend on both artifacts. To fix the errors, such users can exclude their dependency on the ListenableFuture artifact.

However, we recognize that this is confusing and inconvenient. To shield future users from duplicate-class errors, we plan to make Guava depend on an alternative "version" of the ListenableFuture artifact, one that contains no classes because ListenableFuture is already available in Guava. This is similar to the old Version 99 Does Not Exist approach, except that our artifact will live in Maven Central alongside the "real" version. It lets new versions of Guava effectively exclude the dependency on the ListenableFuture artifact, without any action by developers.

We do still anticipate some problems in the meantime, and we're sorry for that. We hope that the value of a lightweight ListenableFuture API outweighs the costs over time. If you are aware of other problems that this change might cause, please let us know. Thanks.

--Chris Povirk, Guava Team