As part of the error-prone effort Tim has been also cleaning other static analysis warnings as reported by IntelliJ's Inspect -> Analyze code. I think this is a good moment to grok some of those too e.g. scoping, unused variables, redundancies, etc. So I hope the others taking part this work try to tackle a chunk of those as well.
Extra note. Of course IntelliJ's code analysis should be judged a bit, there are always fake positives or undesirable changes. On Fri, May 18, 2018 at 7:56 AM Jean-Baptiste Onofré <j...@nanthrax.net> wrote: > Thanks Tim. > I think we will be able to remove findbugs after some run/check using ErrorProne and see the gaps. > Regards > JB > Le 18 mai 2018, à 07:49, Tim Robertson <timrobertson...@gmail.com> a écrit: >> Thank you all. >> I think this is clear. Removing findbugs can happen at a future point. >> @Scott - I've been working through the java IO error prone issues (some already merged, some with open PRs now) so will take those IO Jiras. I will enable failOnWarning, address dependency issues for findbugs and tackle the error prone warnings. >> On Fri, May 18, 2018 at 1:07 AM, Scott Wegner <sweg...@google.com> wrote: >>> +0.02173913 >>> I'm happy to replace FindBugs with ErrorProne, but we need to first upgrade ErrorProne analyzer warnings to errors. Currently the codebase is full of warning spam, and there's no enforcement preventing future violations from being added. >>> I've done the work for enforcing ErrorProne analysis on java-sdk-core [1], and I've sharded out the rest of the Java components in JIRA issues [2] (45 total). Fixing the issues is relatively straightforward, and I've tried to provide enough guidance to make them as starter tasks (example: [3]). Teng Peng has already started on Spark [4] (thanks!) >>> [1] https://github.com/apache/beam/pull/5319 >>> [2] https://issues.apache.org/jira/issues/?jql=project%20%3D%20BEAM%20AND%20status%20%3D%20Open%20AND%20labels%20%3D%20errorprone >>> [3] https://issues.apache.org/jira/browse/BEAM-4347 >>> [4] https://issues.apache.org/jira/browse/BEAM-4318 >>> On Thu, May 17, 2018 at 2:00 PM Ismaël Mejía <ieme...@gmail.com> wrote: >>>> +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
