Generated grpc code cannot be compiled if a underscore is in the name of a method

[johgoe]

Describe the bug

I got a proto file which contains a rpc method with a underscore in the name

syntax = "proto3";

package mypackage;

option java_multiple_files = true;
option java_package = "mypackage";

service MyService {
  // Get info about the service
  rpc service_info(ServiceInfoRequest) returns (ServiceInfo) {}
}
message ServiceInfo {
  string software_version = 1;
}
message ServiceInfoRequest {
}

But the generated code is very inconsistend and cannot be compiled

e.g. in MyServiceImplBase implements io.grpc.BindableService its getServiceinfoMethod instead of getServiceInfoMethod

        @java.lang.Override
        public io.grpc.ServerServiceDefinition bindService() {
            return io.grpc.ServerServiceDefinition.builder(getServiceDescriptor()).addMethod(mypackage.MyServiceGrpc.getServiceinfoMethod(), asyncUnaryCall(new MethodHandlers<mypackage.ServiceInfoRequest, mypackage.ServiceInfo>(this, METHODID_SERVICE_INFO, compression))).build();
        }

causes

[ERROR]   generated-sources/grpc/mypackage/MutinyMyServiceGrpc.java:[73,117] cannot find symbol
[ERROR]   symbol:   method getServiceinfoMethod()
[ERROR]   location: class mypackage.MyServiceGrpc

and in ``MutinyMyServiceStub extends io.grpc.stub.AbstractStub implements io.quarkus.grpc.MutinyStubit isdelegateStub::service_info` instead of `delegateStub::serviceInfo`

        public io.smallrye.mutiny.Uni<mypackage.ServiceInfo> service_info(mypackage.ServiceInfoRequest request) {
            return io.quarkus.grpc.stubs.ClientCalls.oneToOne(request, delegateStub::service_info);
        }

causes

[ERROR]   generated-sources/grpc/mypackage/MutinyMyServiceGrpc.java:[44,72] invalid method reference
[ERROR]   cannot find symbol
[ERROR]     symbol:   method service_info()
[ERROR]     location: class mypackage.MyServiceGrpc.MyServiceStub

Expected behavior

Generated code is consistent and can be compiled

Actual behavior

No response

How to Reproduce?

Download Quarkus sample for grpc.

Add proto example file with name my-service.proto into /src/main/proto, see an example above.

Run mvn package

Output of uname -a or ver

No response

Output of java -version

No response

GraalVM version (if different from Java)

No response

Quarkus version or git rev

No response

Build tool (ie. output of mvnw --version or gradlew --version)

No response

Additional information

No response

[quarkus-bot]

/cc @cescoffier, @michalszynkiewicz

[mkouba]

So according to the style guide for proto buffers you should use CamelCase for service methods. Of course, if you don't control the proto file then it's a problem.

I'll take a look at the generated code.

[mkouba]

I'm not sure why but it seems that the grpc-java compiler attempts to "adjust the service name to follow the JavaBean spec". However, I don't think that the JavaBean spec defines some special rules for methods that are not used to extract properties or events, i.e. it should be legal do define a bean with a method like public String say_Hello() {}.

As a result, if there's a service method like rpc Say_hello (HelloRequest) returns (HelloReply) {} then the original stubs define a method called sayHello() whereas the stubs generated by quarkus define a method say_hello() (lowercase the first char).

So we should probably align the name generated by quarkus to align with the grpc-java compiler (although I'm not quite sure whether the behavior makes a lot of sense).