Generate native image reflect-config.json for java-common-protos

[mpeddada1]

We currently only generate com.google.rpc classes that are used by GAPICs. In cases where handwritten libraries explicitly call other com.google.rpc classes via reflection, we've had to add configurations manually: googleapis/java-spanner#2617.

As pointed out in googleapis/java-spanner#2617 (comment), great care needs to be taken in order to ensure that such classes are covered through configurations if a library chooses to call them reflectively in the future. Generating configs for java-common-protos can mitigate the need for this but comes at a cost of extra configs being generate for the libraries.

[blakeli0]

Thanks @mpeddada1! This is an interesting problem to solve, and it is more like a mini-project in my opinion. There are a few problems I can see:

1. Java-common-protos are mostly generated from google/api, and do not have a java_gapic_library bazel target, hence it does not go through the generator at all at this moment. The bazel script just calls the proto and grpc plugins directly to generate proto and grpc folders accordingly.
2. Assuming we pass these protos to generator, the generator would fail at this moment due to no services found in the protos, see the related issue gapic-generator-java exits with IllegalStateException when there's no service in protos #2050 created by @JoeWang1127.
3. Assuming both of the above issues are solved, where do we want to put the reflect-config.json? Do we want to generate a gapic folder with only the reflect-config.json?

[JoeWang1127]

Java-common-protos are generated from here

I think the java-common-protos are copied from other directories (deep-copy-regex.sources in .Owlbot.yaml).

Am I missing something?

[blakeli0]

Thanks Joe! Yes you are right it is mostly generated from google/api folder, I'll update it to the right link. The problem is still the same that there is no java_gapic_library exist, hence it does not go through the generator.

[mpeddada1]

Thank you @blakeli0 and @JoeWang1127! That is good to know. I wasn't aware of these blockers to implement the static jsons for java-common-protos classes.

3. Assuming both of the above issues are solved, where do we want to put the reflect-config.json? Do we want to generate a gapic folder with only the reflect-config.json?

@burkedavison and I just discussed this offline. Ideally, we want to try to keep these configurations as close as possible to where the classes reside. For google.rpc classes, the preferred location would be in the java-common-protos module if that is achievable?

[mpeddada1]

Documenting another case where confgis for google.rpc classes needed to be manually added: googleapis/java-bigquerystorage#2305

[burkedavison]

Since some handwritten libraries are performing a direct-key error lookup which requires reflection (see googleapis/java-bigquerystorage#2305) rather than gax's iteration method...

We might consider including all ErrorDetails classes in the google-common-protos native config:

sdk-platform-java/gax-java/gax/src/main/java/com/google/api/gax/rpc/ErrorDetails.java

Line 68 in 80f23ec

public RetryInfo getRetryInfo() {

import com.google.rpc.BadRequest;
import com.google.rpc.DebugInfo;
import com.google.rpc.ErrorInfo;
import com.google.rpc.Help;
import com.google.rpc.LocalizedMessage;
import com.google.rpc.PreconditionFailure;
import com.google.rpc.QuotaFailure;
import com.google.rpc.RequestInfo;
import com.google.rpc.ResourceInfo;
import com.google.rpc.RetryInfo;

Alternatively, we could decide that patching these uses at the handwritten library continues to be the appropriate solution.