FindBugs isn’t dead (although my participation had been in hibernation for a while).<p>I’ve been juggling far too many projects, but I’m now working to move FindBugs back into the active rotation.<p>I also want announce I'll be working with GrammaTech as part of the Swamp Project, and they will be helping with rebooting the FindBugs project. This has been in the works for a long time (almost a year), and although I’ve known that GrammaTech was likely to win an award, this hasn’t been official and something I could talk about until recently. Was hoping to have something a little more concrete to talk about as far as that goes; but I don’t yet have the information I wanted to share.<p>Thanks to all the FindBugs fans and supporters who lobbied for me to return to active maintenance of FindBugs. Give me a week to get up to speed on current project needs.<p>Bill Pugh
Google error-prone is a good alternative to FindBugs:<p><a href="https://github.com/google/error-prone" rel="nofollow">https://github.com/google/error-prone</a><p><a href="http://errorprone.info/bugpatterns" rel="nofollow">http://errorprone.info/bugpatterns</a><p>Pros:<p><pre><code> * has faster cycle times and integrates into compilation workflow
* emits fewer false positives
* active maintainers fix issues
* releases several times per year
</code></pre>
Cons:<p><pre><code> * FindBugs has a greater breadth of checks
* current error-prone releases only work with Java 8</code></pre>
Further on in the email chain, it looks like there is momentum for hard forking under another project named 'SpotBugs' [1, 2]. I hope to see the project live on as it has been useful. Other tools like Google's Error Prone and IntelliJ's inspection toolset are awesome, and FindBugs is complimentary to them.<p>[1] <a href="https://mailman.cs.umd.edu/pipermail/findbugs-discuss/2016-November/004330.html" rel="nofollow">https://mailman.cs.umd.edu/pipermail/findbugs-discuss/2016-N...</a><p>[2] <a href="https://github.com/spotbugs/spotbugs" rel="nofollow">https://github.com/spotbugs/spotbugs</a>
Coverity makes a shitload of money off FindBugs. It's annoying they don't contribute back while my organisation pays their most expensive license.
What a shame. I work for a fortune 100 company that enables findbugs on all projects by default. I cannot fathom how many serious issues it's prevented.
If you're an open source project that's expanded to more than a few people, it's worth going through and making a list of all the various "admin" items your project has accumulated (website? domain name? github? bug tracker? mailing lists? etc) and making sure that for each of them there are at least two people with admin rights and that how to add/remove admins is documented. People do drift away from open source projects (or get run over by the proverbial bus) and single points of failure can make things very awkward.
A million downloads, commercial deployments by 3rd parties, and basically no contributions coming in. The status quo of the open-source model. They should start selling it to companies to finance their own work on it. Or encourage others interested in static analysis to do the same.
That's a real shame as I've found FindBugs to be much clearer in its output than many of the commercial offerings (some of which simply wrap FB's output).<p>I hope they can get a new project off the ground and can start rebuilding. We're approaching a time where JVM static analysis tools are going to have to start making some big changes to support upcoming features, and it will be a pity if some version of FB or a successor isn't there.
Sonar, or SonarQube as it's called now, does need more initial config than findbugs. To get a liveable configuration anyway.<p>Once setup though, the quality of analysis is absolutely outstanding.
I'd like to echo the sentiment of everyone else here that would be sad to see the death of Findbugs - When the draft of JSR-305 was released, I was hoping to see an array of tools that would almost be "standardized" around the static code analysis annotations. I'm working on reviving that JSR and will see if I can chat with Dr. Pugh as well.
I don't have a Twitter account, so maybe I'm missing something about the difficulty here. But the author spent paragraphs describing how the fate of this major thing is largely in the hands of Bill Pugh, he can't reach Bill Pugh via email, maybe his email is expired, etc. etc. can someone please help contact him via phone or twitter or whatever?<p>Why not just create a twitter account and do it yourself? WTF?<p>edit: presumably one of the downvoters is working right this minute to contact Bill Pugh via Twitter and put him in touch with the author, because that totally makes sense
What a shame - it caught a few bugs in my code and has definitely made me a better programmer.<p>One of the reasons is that the code is hard to maintain with most open source contributions being small improvements. How have other open source projects handled large scale refactors? Is it as simple as someone creating something new from scratch and then duplicating functionality? Are there examples of large open source projects that have had ground up rewrites?
For those looking for an alternative, I've had reasonable success with PMD: <a href="https://pmd.github.io/" rel="nofollow">https://pmd.github.io/</a>
I just had a quick look at the repo and I'm not particularly familiar with the project but what's the issue with just doing a hard fork if there are enough people who want this to keep going?
Interestingly, the spirit of the FindBugs project lives on in the development of languages like Rust and Swift, considering the purpose of the FindBugs project is to fix inherent flaws in Java, e.g. not having a way to determine whether something will be null, or not telling you whether you checked whether something will be null at runtime, etc.