+0.7 also. Findbugs support for more recent versions of Java is lacking and the maintenance seems frozen in time.
As a possible plan b can we identify the missing important validations to identify how much we lose and if it is considerable, maybe we can create a minimal configuration for those, and eventually migrate from findbugs to spotbugs (https://github.com/spotbugs/spotbugs/) that seems at least to be maintained and the most active findbugs fork. On Thu, May 17, 2018 at 9:31 PM Kenneth Knowles <k...@google.com> wrote: > +0.7 I think we should work to remove findbugs. Errorprone covers most of the same stuff but better and faster. > The one thing I'm not sure about is nullness analysis. Findbugs has some serious limitations there but it really improves code quality and prevents blunders. I'm not sure errorprone covers that. I know the Checker analyzer has a full solution that makes NPE impossible as in most modern languages. Maybe that is easy to plug in. The core Java SDK is a good candidate for the first place to do it since it is affects everything else. > On Thu, May 17, 2018 at 12:02 PM Tim Robertson <timrobertson...@gmail.com> wrote: >> Hi all, >> [bringing a side thread discussion from slack to here] >> We're tackling error-prone warnings now and we aim to fail the build on warnings raised [1]. >> Enabling failOnWarning also fails the build on findbugs warnings. Currently I see places where these arise from missing a dependency on findbugs_annotations and I asked on slack the best way to introduce this globally in gradle. >> In that discussion the idea was floated to consider removing findbugs completely given it is older, has licensing considerations and is not released regularly. >> What do people think about this idea please? >> Thanks, >> Tim >> [1] https://lists.apache.org/thread.html/95aae2785c3cd728c2d3378cbdff2a7ba19caffcd4faa2049d2e2f46@%3Cdev.beam.apache.org%3E
