+1 Even if I like the strictness for Null checking, I also think that this is adding too much extra time for builds (that I noticed locally when enabled) and also I agree with Jan that the annotations are really an undesired side effect. For reference when you try to auto complete some method signatures on IntelliJ on downstream projects with C-A-v it generates some extra Checkers annotations like @NonNull and others even if the user isn't using them which is not desirable.
On Mon, Mar 15, 2021 at 6:04 PM Kyle Weaver <[email protected]> wrote: >> >> Big +1 for moving this to separate CI job. I really don't like what >> annotations are currently added to the code we ship. Tools like Idea add >> these annotations to code they generate when overriding classes and that's >> very annoying. Users should not be exposed to internal tools like >> nullability checking. > > > I was only planning on moving this to a separate CI job. The job would still > be release blocking, so the same annotations would still be required. > > I'm not sure which annotations you are concerned about. There are two > annotations involved with nullness checking, @SuppressWarnings and @Nullable. > @SuppressWarnings has retention policy SOURCE, so it shouldn't be exposed to > users at all. @Nullable is not just for internal tooling, it also provides > useful information about our APIs to users. The user should not have to guess > whether a method argument etc. can be null or not, and for better or worse, > these annotations are the standard way of expressing that in Java.
