CompletableFuture stubs

[rmichela]

Hello, I'd like to start a discussion about adding a CompletableFuture-based stub implementations to gRPC. I understand that generated gRPC code must be backwards compatible with Java 6, so here are some alternative implementation strategies to consider.

1. Implement CompletableFuture-based stubs in a stand-alone class generated by a stand-alone protoc plugin. The CF stub class would reference the public MethodDescriptors of the stock generated client. This option is easiest to implement, but presents a fragmented programming model.
2. Implement CompletableFuture-based stubs inline with the existing generated stubs by adding @@protoc_insertion_points to the stock c++ generator. A protoc plugin would be used to populate the insertion points. This option has the benefit of presenting a homogenous programming model for this, and all future plugin-based stub extensions, but requires a coordinated one time change with the protoc project.
3. Extend the c++ generator with optional support for CompletableFuture. Use a protoc flag to turn it on and off. Not a great option, but possible.

[carl-mastrangelo]

Guava might have to face this sooner than we do, so they may make their futures Completable anyways, and you could just cast. gRPC could just ride this out.

[rmichela]

I get the impression from #2688 that Guava upgrades are problematic. Would Guava vNext introduce the same compatibility break that Guava 20 introduced?

[ejona86]

I just saw that Guava recommends future-converter.

[keithl-stripe]

FYI a comment in #6986 suggests that this will not happen anytime soon.

[ejona86]

#4671 tracks dropping Java 7 support and in #8100 warnings were issued when running on Java 7. Dropping Java 7 may happen this year.

But dropping Java 7 just lets us use Java 8 language features, because older Android versions don't have the Java 8 libraries. For this specific issue, we could maybe add CompletableFuture to full-proto codegen and not lite-proto codegen. Or we rely on users not to call the methods they can't use. But that'd have to be worked out.

[silospen]

@ejona86 Can you help me understand the current state of CompletableFuture support in GRPC now that Java 7 looks to have been removed (congrats, btw, that's a big deal!)?

[ejona86]

@silospen, Java 7 is dropped, but Android API level 19 is still supported. So what we mainly got was access to language features. We don't yet require Android users to enable library desugaring, which would be required to use CompletableFuture until we require API level 24+.

Note that the problem isn't as much the generated code as javalite codegen is separate from full protobuf. But the codegen uses grpc-stub for support, and that is still used on Android.