Lázaro Clapp

Note that the following workaround would be sufficient for NullAway to know that the code is safe (though, in the case with `final`, I agree this shouldn't be needed): ```...

This is an unfortunate consequence of #446 . Basically, since we are not allowing library models to affect annotated code anymore (due to the "inherited annotations" issue), after NullAway 0.9.0,...

It is a bit more complicated than just saying "this are the target packages that I'm analyzing", because - at least for us, in our monorepo - there is a...

I am not familiar with Reactor, and we don't have any immediate plans to add support for it ourselves, but we would be open to someone contributing it. Based on...

The answer is always yes! We are happy to look at a PR on this or answer any questions required to design this.

> initializer method does not guarantee @NonNull field after (line 16) is initialized along all control-flow paths Means the constructor doesn't guarantee field `after` is non-null. Since the field `after`...

Hey @xenoterracide , the error includes the field name: "initializer method does not guarantee @nonnull field **_after_** (line 16) is initialized along all control-flow paths". Unfortunately, the name of the...

Basically, I agree that the long term solution is bytecode rewriting to add the annotations, which further buys us Kotlin support automatically. As for the short term solutions, I see...

Basic NullAway on Java 11 should work, we'd be happy to look at an issue here with a repo case.

Didn't recall the entire discussion when I made this change, but this ended up being solution (3) from this comment: https://github.com/uber/NullAway/issues/453#issuecomment-789129985 I wonder if it's still worth it to take...