FindBugs project in its current form is dead • Hacker News Board

Re: FindBugs project in its current form is dead

#61

Post by lowry » Sun, Nov 06, 2016, 8:10 PM UTC

achou wrote: post #58

unreal37 wrote: post #55

Earlier quoted context omitted.

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++.

True for my organisation as well. Most of the code is C/C++. So it would make business reason to support the community of the open source product that does not directly compete with Coverity while using it to complement the business offer.

Re: FindBugs project in its current form is dead

#62

Post by achou » Sun, Nov 06, 2016, 8:15 PM UTC

lowry wrote: post #59

achou wrote: post #52

Earlier 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…

Coverity Scan is a marketing tool. As for FindBugs integration... The majority of Coverity issues I deal with are labelled as FindBugs issues.

Scan finds lots of bugs for open source projects at no cost. Sure it is marketing, but unlike most marketing it also has real value.

Not sure I can comment on the results on your own code, but I will say that volume of results is not always correlated with value in static analysis. There are plenty of noisy rules that basically have negative utility if you factor in the time it takes to review each issue. It's a complex balancing act between finding more issues, having fewer false positives, analysis time, understandability of results, and other factors.

Re: FindBugs project in its current form is dead

#63

Post by Seol » Sun, Nov 06, 2016, 8:55 PM UTC

gaul wrote: post #22

Google 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

Also, error-prone works in a fundamentally different way to FindBugs: error-prone is a compiler plugin, whereas Findbugs is an after-the-fact static analyser. This means, for example, you can include dependencies on the codebase you're analysing in your findbugs checks, but not in error-prone.

This turns out to be really quite relevant if you're building domain-specific static analysis checks, as opposed to just running standard analyses.

Re: FindBugs project in its current form is dead

#64

Post by wodencafe » Sun, Nov 06, 2016, 8:56 PM UTC

justin66 wrote: post #8

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? Why not just create a twitter account and do it yourself? WTF? edit: pre…

Bill actually replied to this HN thread.

Re: FindBugs project in its current form is dead

#65

Post by aardvark179 » Sun, Nov 06, 2016, 8:59 PM UTC

billpugh wrote: post #49

FindBugs 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…

That's great, but it feels you have been a single point of failure on a widely used project. As well as rebooting the project do you have any plans to expand the admin role so it's harder for the project to find itself in this situation in the future?

Re: FindBugs project in its current form is dead

#66

Post by [deleted] » Sun, Nov 06, 2016, 8:59 PM UTC

billpugh wrote: post #49

FindBugs 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…

[deleted]

Re: FindBugs project in its current form is dead

#67

Post by dmuth » Sun, Nov 06, 2016, 9:05 PM UTC

unreal37 wrote: post #53

billpugh wrote: post #49

FindBugs 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.

^ this. There is absolutely no reason to not be answering emails, even if to say, "I'm really swamped, and need help."

I don't mean to denigrate you, but I must be candid here: hoarding admin rights so that only you have them and no one else can get any work done is simply not acceptable in a team environment.

Going forward, I would recommend taking a look through other projects you may be involved with, and make sure that you are not the only person with admin access. If nothing else, it would increase the "bus factor" to greater than 1: https://en.wikipedia.org/wiki/Bus_factor

Good luck.

Re: FindBugs project in its current form is dead

#68

Post by nstj » Sun, Nov 06, 2016, 9:49 PM UTC

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?

Re: FindBugs project in its current form is dead

#69

Post by needusername » Sun, Nov 06, 2016, 10:05 PM UTC

Seol wrote: post #63

gaul wrote: post #22

Google 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

Also, error-prone works in a fundamentally different way to FindBugs: error-prone is a compiler plugin, whereas Findbugs is an after-the-fact static analyser. This means, for example, you can include dependencies on the codebase you're analysing in your findbugs checks, but not in error-prone. This turns out to be really quite relevant if you're building domain-specific static analysis checks, as opposed to just runn…

> error-prone is a compiler plugin

Can you provide more information on how this is achieved? As far as I know there is no official, supported, portable API for Java compilers. The only thing I'm aware of is APT and anything beyond that would require significant rearchitecture of the existing compilers.

Re: FindBugs project in its current form is dead

#70

Post by needusername » Sun, Nov 06, 2016, 10:09 PM UTC

jbangert wrote: post #57

nothrabannosir wrote: post #44

Earlier quoted context omitted.

> 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).

Haven't we learnt several times in the past that this is a bad idea? Eg. with Android or GAE/J. This is going to require a lot of effort for every upcoming Java release delaying support for a long time, again see Android or GAE/J. It also makes integration with Eclipse difficult at best.