I enabled the grpc-java-api-checker tool on the grpc-java repo's examples directory, and found that this line triggers an @Internal API usage error. This is because NettyChannelBuilder (and OkHttpChannelBuilder) extend io.grpc.internal.AbstractManagedChannelImplBuilder but do not override it's build() method, and according to the package-info.java for io.grpc.internal, everything in this package has the @Internal annotation.

I don't think we want this to trigger the error, although technically it is use of an @Internal API - but it's via the non-internal NettyChannelBuilder class, so it seems like it should be "allowed" by grpc-java-api-checker.

@jyane any thoughts? The ASTHelper class does have methods to check for the declaration of super methods. E.g., we could "solve" this particular problem with something like:

  /**
   * Returns the description if tree is annotated.
   */
  private Description match(Tree tree, VisitorState state) {
    Symbol symbol = ASTHelpers.getSymbol(tree);
    if (symbol == null) {
      return NO_MATCH;
    }
    if (symbol instanceof MethodSymbol) {
      MethodSymbol methodSymbol = (MethodSymbol) symbol;
      Optional<MethodSymbol> superSymbol = 
          ASTHelpers.findSuperMethod(methodSymbol, state.getTypes());
      if (superSymbol.isPresent()) {
        symbol = superSymbol.get();
      }
    }
    AnnotationMirror annotation = findAnnotatedApi(symbol);
    if (annotation == null) {
      return NO_MATCH;
    }
    return describe(tree, annotation);
  }

But this would need to also check if the direct method being invoked had an @Internal annotation, e.g., if NettyChannelBuilder.build() was explicitly annotated as @Internal then we'd probably still want to have the tool match this, even though the super method on ManagedChannelBuilder is not internal. (hasDirectAnnotationWithSimpleName would probably be helpful here)