Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

bindService() should be final #2552

Closed
zhangkun83 opened this issue Dec 22, 2016 · 0 comments
Closed

bindService() should be final #2552

zhangkun83 opened this issue Dec 22, 2016 · 0 comments
Labels

Comments

@zhangkun83
Copy link
Contributor

We just found out a method in the generated code

The method is "bindService()" on the generated server interface is supposed to be "final", but is currently not.

For example

public abstract class RouteGuideImplBase {
  // Empty implementations, to be overridden by the application
  public StreamObserver routeSingle(StreamObserver) {
    failWithUnimplemented();
  }
  public StreamObserver routeMultiple(StreamObserver) {
    failWithUnimplemented();
  }

  // Glue code called by gRPC server to register the service.
  // Not supposed to be overridden.
  public bindService() {
    ...
  }
}

Why is it an issue

The non-final bindService() adds difficulty for users who want to mock the server interface in their tests. Mockito by default overrides all non-final methods with its no-op and null-returning impl. When a Mockito user creates a mock for RouteGuideImplBase, it can't be correctly registered to the server. It can be worked around by explicitly telling Mockito to use the original bindService(), but it's still a friction in the user experience.

What should we do

bindService() should have been defined as "final" in the first place. It was an oversight that we didn't make it so. This should be considered as a bug and be fixed.

We will make the change in master, which will be in 1.1.0.

Risk

This is technically an incompatible API change. Anyone overrides bindService() on the generated interface will be broken. However, I don't find anyone doing so in google3, or any legitimate reason for it in general. The chance of breaking anyone is very low.

@zhangkun83 zhangkun83 added the bug label Dec 22, 2016
@lock lock bot locked as resolved and limited conversation to collaborators Sep 22, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

1 participant