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.

[credmond-git]

@ejona86 has their been any updates to this? Looking at the supported API level as of last Aug, the minimum API level is 30? Although please correct me if i am reading this incorrectly.
Supporting more modern java features such as CompletableFutures would make it easier to work with gRPC.
It looks like you removed support for 24 already in 9792c9f
Although API 21 may still be supported by Google Play Services.

[ejona86]

API level 30 is the target API level in those docs. You can have a much lower minimum API level for your app. Target API level means the app is conforming to any new restrictions and behaviors of the new Android version. The minimum API level is the smallest API level your app will work with.

We are still supporting API level 21, as mentioned in our README. Those tests we removed because the emulators were no longer available in Firebase. Those old versions were just reporting SKIPPED, and so were doing nothing.