guava-27.0-jre.jar contains failureaccess class files

I tried upgrading to guava 27.0 in my project and noticed a new warning at build time:

[WARNING] guava-27.0-jre.jar, failureaccess-1.0.jar define 2 overlapping classes:
[WARNING]   - com.google.common.util.concurrent.internal.InternalFutureFailureAccess
[WARNING]   - com.google.common.util.concurrent.internal.InternalFutures
[WARNING] maven-shade-plugin has detected that some class files are
[WARNING] present in two or more JARs. When this happens, only one
[WARNING] single version of the class is copied to the uber jar.
[WARNING] Usually this is not harmful and you can skip these warnings,
[WARNING] otherwise try to manually exclude artifacts based on
[WARNING] mvn dependency:tree -Ddetail=true and the above output.
[WARNING] See http://maven.apache.org/plugins/maven-shade-plugin/

Indeed, I can see those .class files in the guava-27.0-jre.jar I downloaded from Maven. Are those class files supposed to be there? I ask because it seems like they are supposed to be in the failureaccess jar only, but they were included in the guava jar by mistake.

[jodastephen]

@cgdecker The approach you have taken to splitting out a submodule is indeed very standard, and well suited to corporate codebases and larger projects. But for a foundational library like Guava it is far from ideal. Put simply, it is not the case that all users ignore the number of jar file dependencies - for some users, details of, and number of, those dependencies really matters,

There are going to be plenty of projects that have a dependency on Guava and nothing else. Those projects will now be seeing a tripling of the number of dependencies. This affects me (more or less) with Joda-Beans and Joda-Convert.

In addition, many projects (like OpenGamma Strata) have to list all their dependencies in user documentation, and the version numbers thereof. The change requires both new dependencies to be added to the docs, and some kind of additional note added to try and explain the horrible v9999 hack.

In essence this gives the appearance of Google making a change for its convenience (Android) rather than providing stability and security for non-Google users, which is what some of us have worried about all along with Guava. Particularly as now the floodgates of dependencies are open I fear we willl see Guava split into many more jar files.

[jodastephen]

@cgdecker Removing these classes from the main jar is not the right solution though. We care about the number of jar file dependencies, so splitting Guava into multiple pieces is very painful. And pushing a v9999 hack on the world really is a gross failure on the part of Guava maintainers.

Given that you have separate releases for -jre and -android, surely the -jre release should just be a single jar file, with the -android release split into pieces. This would avoid all the problems you are seeing.