Hi,
I created the issue in JetBrains tracker [1]. I'm still not 100%
convinced that it is correct for the checker to actually modify the
bytecode. An open questions is - in guava this does not happen. Does
guava apply the check on code being released? From what is in this
thread is seems to me, that the answer is no.
Jan
[1] https://youtrack.jetbrains.com/issue/IDEA-265658
On 4/1/21 6:15 AM, Kenneth Knowles wrote:
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
<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]
<mailto:[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
@Override public 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]>
<mailto:[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.
