Regarding splitting away `ListenableFuture` from Guava

This issue is a follow-on from the discussion started by @jodastephen at https://github.com/google/guava/issues/3302#issuecomment-435836131 about the recent introduction of the com.google.guava:listenablefuture and com.google.guava:failureaccess dependencies.

To summarise, when @cpovirk is back from leave, I’d love to hear his reasoning for the introduction of the two new artifacts, and to discuss things (whether publicly or privately) with both @cpovirk and @jodastephen to see if it would be possible to achieve what the Android Support library authors would like (being able to use ListenableFuture in the Android SDK, IIUC) whilst satisfying @jodastephen and myself (keeping Guava as one artifact, or as close to this as possible).

[jodastephen]

As it stands, I have no desire to upgrade Guava beyond v26, which could be a problem if there is a security issue.

In OpenGamma Strata, we have to list all dependencies (including transient), so the new setup (particularly the v9999 hack) is problematic (just try explaining it!).

In Joda-Collect, this change triples the number of dependencies. Things are not much different in Joda-Beans and Joda-Convert.

My proposal is that Guava v28-jre has no dependencies, but v28-android does. From a quick look at the code, I don’t see why that wouldn’t work.

[jodastephen]

Thank you for responding. Unfortunately, it doesn’t really provide a route forward for those of us that care about dependencies (and find the 9999 hack completely unacceptable). As it stands, we are stuck on v26.

And the benefits are smaller, likely even zero

No, the benefits are not zero, they are negative.

I have to stress again, dependency count is really important for libraries, and especially low level ones because each dependency added has a multiplier effect up the stack. Ultimately, each dependency that a library has increases the chance of jar hell for someone in the large-systems you discuss. Developers like me are trying to reduce and minimize the pain for large-systems, changes like this really don’t help.

I’ll ask again, why not make v28-jre a single jar, while the android release is split? The jre release is Java 8+, where CompletableFuture provides what many would argue is a superset of the benefits of ListenableFuture (thus making it a complete irrelevance to break out ListenableFuture into a separate jar).

However this thread ends, it does feel like Guava has damaged the trust that allowed it to be effectively an extension to the JDK.