Would it be possible to shade guava?

Please answer these questions before submitting your issue.

What version of gRPC are you using?

1.0.3 and 1.1.1

What JVM are you using (java -version)?

java version “1.8.0_92” Java™ SE Runtime Environment (build 1.8.0_92-b14) Java HotSpot™ 64-Bit Server VM (build 25.92-b14, mixed mode)

What did you do?

GRPC 1.1+ uses Guava 20.0. We have a very large codebase that uses both internal and external libraries that depend on older version of guava. These libraries are not compatible with Guava 20.0. As a result we are unable to upgrade to GRPC 1.1.+. From what I can tell the only Guava class exposed by GRPC is ListenableFutures, via ClientCalls in grpc-stub. Would it be possible to shade all other uses of Guava in GRPC.

There would still be an issue with the GRPC code generator that does expose Guava’s ListenableFuture. For that use case would it be possible to make generating those stubs optional and perhaps even add an option to generate a CompletableFuture stub?

What did you expect to see?

Newer versions of GRPC to not break other libraries depending on older version of Guava.

What did you see instead?

[elandau]

@ejona86 Sticking with Guava 19 sounds fine. Do you plan to upgrade to Guava 22 with its compatibility layer once it’s release?

What about the option to no longer expose Guava in the stubs and generated code? Would you consider having a generator option to disable the ListenableFuture stubs and another option to generate CompletableFuture stubs? I’d be more than happy to submit a PR for that but want to make sure you think this approach makes sense.

[GEverding]

Case and point grpc 1.1.x Isn’t compatible with datastax cassandra driver 3.x.