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, à 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/95aae2785c3cd728c2d3378cbdff2a >>> 7ba19caffcd4faa2049d2e2f46@%3Cdev.beam.apache.org%3E >>> >>
