as the current test setup doesn't allow defining a class that extends any @internal classes

IMO, I want to add some tests if it could be, but it will make codes be weird. The package name is available via Compilation Unit Tree. Compilation Unit Tree is usually a root of Java AST so It could find via several ways.

1. Implements CompilationUnitTreeMatcher and check the package name something like: https://github.com/jyane/obsolate/blob/fe89d7f295a81fe94725009ed856561ebac1834f/src/main/java/com/github/jyane/grpc/annotations/checkers/AnnotationChecker.java#L92-L104 but it will be stateful.

2. Find enclosing CompilationUnitTree by travarsing a AST. Something like ASTHelper.findEnclosingNode(state.getPath(), CompilationUnitTree.class), it is stateless but O(N). (N is height of the AST.)

If you(and me) want to add the checker to grpc-java examples, we could extend and override a method (verify the package name) only in tests... All of the ways I came up...

If you want to leave the test alone, I will approve. I've checked this changes by grpc-java examples as well.

Thanks for looking at this @jyane. @ejona86 is out until Monday, and I want to wait to get his feedback on the semantics of @Internal (as discussed in #13) before merging this anyways.

Re: the tests - ideally we would be able to include source code in the tests that does not get validated by the checker. This way, in the test set up, we can define some "gRPC library code" that does reference @Internal APIs (and would fail if the checker ran on it), and then define the "user" code that does get validated by the checker and references the "gRPC library code".

If that's not easily achievable with the existing test infrastructure, an alternate approach could be to combine your suggestion (override part of the checker in the tests) with a test-only "@IgnoreForTest" annotation that we could add to the tested source code where necessary.

I'm more or less comfortable merging this without unit tests (pending @ejona86's feedback) since we've verified it manually; but getting test coverage should definitely at least be a follow-up item.

@ericgribkoff and I spoke offline. I think simply "a non-@Internal method" is enough to avoid marking it Internal.

@ejona86 Thanks!
@ericgribkoff Would you please answer my question? #14 (comment) I don't quite follow, you want to override it on tests?

@jyane Thanks, I made the variable final.

I also changed the semantics, as suggested by @ejona86. A method only counts as @Internal if it and all of super methods are annotated.