Hi all, About the IntelliJ automatic method stub issue: I raised it to the checkerframework list and got a helpful response: https://groups.google.com/g/checker-framework-discuss/c/KHQdjF4lesk/m/dJ4u1BBNBgAJ
It eventually reached back to Jetbrains and they would appreciate a detailed report with steps to reproduce, preferably a sample project. Would you - Jan or Ismaël or Reuven - provide them with this issue report? It sounds like Jan you have an example ready to go. Kenn On Mon, Mar 15, 2021 at 1:29 PM Jan Lukavský <[email protected]> wrote: > Yes, annotations that we add to the code base on purpose (like @Nullable > or @SuppressWarnings) are aboslutely fine. What is worse is that the > checked is not only checked, but a code generator. :) > > For example when one wants to implement Coder by extending CustomCoder and > use auto-generating the overridden methods, they look like > > @Overridepublic void encode(Long value, @UnknownKeyFor @NonNull @Initialized > OutputStream outStream) throws @UnknownKeyFor@NonNull@Initialized > CoderException, @UnknownKeyFor@NonNull@Initialized IOException { > > } > > Which is really ugly. :-( > > Jan > > On 3/15/21 6:37 PM, Ismaël Mejía wrote: > > +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]> > <[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. > >
