core,README: add docs about grpc-java-api-checker#4182
core,README: add docs about grpc-java-api-checker#4182ericgribkoff merged 4 commits intogrpc:masterfrom
Conversation
ericgribkoff
left a comment
There was a problem hiding this comment.
Thanks for doing this! A couple comments below.
|
|
||
| Tools | ||
| ----- | ||
| APIs that are annotated with `@ExperimentalApi` are subject to change, and APIs |
There was a problem hiding this comment.
I think we want to aim this more at library code that uses gRPC, as they may have less control of the ultimate gRPC version that gets used than an application developer directly using gRPC. Something like:
APIs that are annotated with
@ExperimentalApiare subject to change, and APIs that are annotated with@Internalare for internal use by the gRPC library. Because APIs with these annotations could be modified or even removed in a future release, library code that other projects may depend on should not use these APIs. We recommend using the grpc-java-api-checker (an Error Prone plugin) to check for usages of@ExperimentalApiand@Internalin any library code that depends on gRPC.
There was a problem hiding this comment.
I thought all users should not use @Internal APIs. I respect your opinion :)
There was a problem hiding this comment.
That's fair. We have the wording in @Internal's javadoc about using these APIs to implement a custom load balancer or transport, but that's probably fine to leave out here:
APIs annotated with
@Internalare for internal use by the gRPC library and should not be used by gRPC users. APIs annotated with@ExperimentalApiare subject to change in future releases, and library code that other projects may depend on should not use these APIs. We recommend using the grpc-java-api-checker (an Error Prone plugin) to check for usages of@ExperimentalApiand@Internalin any library code that depends on gRPC. It may also be used to check for@Internalusage or unintended@ExperimentalApiconsumption in non-library code.
Currently quite a lot of our APIs are marked experimental, so I think the "you should not use @ExperimentalApi" statement in the original text is too strong. @ejona86 WDYT?
There was a problem hiding this comment.
Oops, the load balancer reference is out-dated. Sent out #4192
Yeah, "not use" is too strong. For the library piece I think I'd say something closer to "Since libraries can not generally guarantee which version of gRPC is being used, most libraries should not use APIs annotated with @ExperimentalApi." But @ericgribkoff's most recent suggested text looks fine.
| * <p>Note: This annotation is intended only for gRPC library code. Users should not attach this | ||
| * annotation to their own code. | ||
| * annotation to their own code. If you want to check APIs' usage, you can use | ||
| * grpc-java-api-checker. |
There was a problem hiding this comment.
How about:
* @see <a href="https://github.com/grpc/grpc/grpc-java-api-checker">grpc-java-api-checker</a>, an
* Error Prone plugin to automatically check for usages of this API.
(Same for Internal.java)
99acd0d to
a8ff84c
Compare
|
@ericgribkoff PTAL |
|
Wait... checkstyles are failed... I will fix it. |
|
I've fixed but I've found new warnings on and It could be reproduced on my local machine. Using a link with strings might not be permitted. Thus, I've removed |
|
I want to merge this PR once |
|
Thanks! |
No description provided.