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.
FindBugs project in its current form is dead
51–60 of 121 posts
Re: FindBugs project in its current form is dead
#52Coverity makes a shitload of money off FindBugs. It's annoying they don't contribute back while my organisation pays their most expensive license.
Um, Coverity contributes a lot to the open source community through Scan[1].
While Coverity does incorporate Findbugs results, it also has its own analyzer that does much more interprocedural analysis and tends to be tuned better for fewer false positives and more accurate error messages. Historically at least, part of the reason for incorporating Findbugs was to make it easier to directly compare what Findbugs found with what Coverity's analyzer found. Because every customer wanted to know that.
I have no idea of current figures but historically Java was not a big business for Coverity. Other vendors had much more Java business (and incidentally also incorporated Findbugs results).
Finally, as you can see from the message the Findbugs leadership does not seem unified and easy to collaborate with.
So forgive me but I find your comment and its tone a bit unfair.
Re: FindBugs project in its current form is dead
#53FindBugs isn’t dead (although my participation had been in hibernation for a while). I’ve been juggling far too many projects, but I’m now working to move FindBugs back into the active rotation. 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 kn…
It's still not a good sign that it took this level of public attention to get you to reply to the active community on their urgent needs.
Re: FindBugs project in its current form is dead
#54FindBugs isn’t dead (although my participation had been in hibernation for a while). I’ve been juggling far too many projects, but I’m now working to move FindBugs back into the active rotation. 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 kn…
It's still not a good sign that it took this level of public attention to get you to reply to the active community on their urgent needs.
Indeed. Probably having more people with admin access would help making sure that the project's bus factor is greater than 1 :)
Re: FindBugs project in its current form is dead
#55Coverity makes a shitload of money off FindBugs. It's annoying they don't contribute back while my organisation pays their most expensive license.
Um, Coverity contributes a lot to the open source community through Scan[1]. While Coverity does incorporate Findbugs results, it also has its own analyzer that does much more interprocedural analysis and tends to be tuned better for fewer false positives and more accurate error messages. Historically at least, part of the reason for incorporating Findbugs was to make it easier to directly compare what Findbugs found…
I see you are the founder of Coverity.
It might seem unfair, but you stated that "every customer wanted to know that". So that project has value to you.
Re: FindBugs project in its current form is dead
#56I 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? Why not just create a twitter account and do it yourself? WTF? edit: pre…
If he's avoiding thinking about this, then it doesn't matter what the communications channel is except "in person" or "email from a close friend".
Re: FindBugs project in its current form is dead
#57Google error-prone is a good alternative to FindBugs: https://github.com/google/error-prone http://errorprone.info/bugpatterns Pros: * has faster cycle times and integrates into compilation workflow * emits fewer false positives * active maintainers fix issues * releases several times per year Cons: * FindBugs has a greater breadth of checks * current error-prone releases only work with Java 8
> current error-prone releases only work with Java 8 I'm assuming that means it will only run on the JVM8, but it can analyze any version of Java code?
Error-prone is somewhat tied to a specific version of the Java compiler -- so you need Javac 8, but you can set --source to an older version of the language. If the newer Javac does not emit bytecode that works with your runtime, you can run two compiles (one error-prone for the errors, one production compile with whatever compiler you need).
Re: FindBugs project in its current form is dead
#58Earlier quoted context omitted.
Um, Coverity contributes a lot to the open source community through Scan[1]. While Coverity does incorporate Findbugs results, it also has its own analyzer that does much more interprocedural analysis and tends to be tuned better for fewer false positives and more accurate error messages. Historically at least, part of the reason for incorporating Findbugs was to make it easier to directly compare what Findbugs found…
I see you are the founder of Coverity. It might seem unfair, but you stated that "every customer wanted to know that". So that project has value to you.
I should be more clear: every customer using Java wanted to know how our custom developed analysis compared with what Findbugs could find.
There weren't all that many such customers though (again, historically). A more typical customer was developing in C/C++.
Re: FindBugs project in its current form is dead
#59Coverity makes a shitload of money off FindBugs. It's annoying they don't contribute back while my organisation pays their most expensive license.
Um, Coverity contributes a lot to the open source community through Scan[1]. While Coverity does incorporate Findbugs results, it also has its own analyzer that does much more interprocedural analysis and tends to be tuned better for fewer false positives and more accurate error messages. Historically at least, part of the reason for incorporating Findbugs was to make it easier to directly compare what Findbugs found…
Coverity Scan is a marketing tool. As for FindBugs integration... The majority of Coverity issues I deal with are labelled as FindBugs issues.
Re: FindBugs project in its current form is dead
#60Google error-prone is a good alternative to FindBugs: https://github.com/google/error-prone http://errorprone.info/bugpatterns Pros: * has faster cycle times and integrates into compilation workflow * emits fewer false positives * active maintainers fix issues * releases several times per year Cons: * FindBugs has a greater breadth of checks * current error-prone releases only work with Java 8
I really wish it had a maven plugin.
Looks like it does? http://errorprone.info/docs/installation