Consider supporting Guava 19 in grpc-api

As requested by @adriancole at https://github.com/grpc/grpc-java/pull/5590#issuecomment-482784097 .

I worked to remove major ecosystem incompatibilities with Guava 20 starting in 2017 and claimed victory in 2018. See #4176 to follow the chain. Guava 20 was released in 2016, so I do have limited sympathy for libraries that remain incompatible, especially since every occurrence I’ve seen has included at least one @Beta API.

Supporting Guava 19 is a bit difficult from a testing perspective, unless we depend directly on Guava 19. If we continue compiling against Guava 20+ it’s likely regressions will be introduced. Depending on Guava 19 directly would be unfortunate and hurts us getting to Guava 27, which we need to avoid Android dependency issues with listenablefuture and failureaccess.

@adriancole, I generally expect to know what libraries are incompatible with newer Guava versions and get some agreement from their maintainers they are working on the issue. That way I can track progress and know when we can use the newer Guava. What libraries are causing the trouble?

Also, note that we don’t generally support users downgrading our published dependencies. We did “make it work” for a while for older Guava versions after we became aware it was wide-spread, but downgrading dependencies is not something that is acceptable without informing upstream.

I just tested and grpc-api is API-compatible with Guava 19. I think I’d take the approach of having our own Preconditions class in io.grpc that we use instead for the while. It can still call Guava’s Preconditions, but it will ensure we only call overloads that are available in Guava 19. Note that this will cause more garbage creation, since the overloads were added in Guava 20 as a performance optimization. For cases where the garbage may be costly, we could implement the method ourselves. @adriancole, does that sound like a fine approach?

[pan3793]

IMHO, guava maybe the most conflict-prone package in Java world. As infra library, I will appreciate it if grpc and protobuf remove guava dependency, ideally they should be zero-dependencies.

[ejona86]

The Java Servlet Specification discusses this some in SRV.9.7.2, but it is sort of hand-wavy.

The class loader that a container uses to load a servlet in a WAR must allow the developer to load any resources contained in library JARs within the WAR following normal J2SE semantics using getResource. As described in the J2EE license agreement, servlet containers that are not part of a J2EE product should not allow the application to override J2SE platform classes, such as those in the java.* and javax.* namespaces, that J2SE does not allow to be modified. Also, servlet containers that are part of a J2EE product should not allow the application to override J2SE or J2EE platform classes, such as those in java.* and javax.* namespaces, that either J2SE or J2EE do not allow to be modified. The container should not allow applications to override or access the container’s implementation classes. It is recommended also that the application class loader be implemented so that classes and resources packaged within the WAR are loaded in preference to classes and resources residing in container-wide library JARs.

I’m actually not sure what the last sentence implies, since it was already mentioned that the app shouldn’t be able to access “container’s implementation classes.”

Tomcat’s behavior: https://github.com/apache/tomcat/blob/f98e99d/java/org/apache/catalina/loader/WebappClassLoaderBase.java#L1251 . It first tries to load from the system class loader, then the webapp’s class loader, then the parent class loader.