[FB-Discuss] Project status

Thrawn shell_layer-github at yahoo.com.au
Tue Nov 8 18:15:35 EST 2016


> Now there are two new projects/forks started
> - SportBugs https://github.com/spotbugs/spotbugs/
> - HuntBugs https://github.com/amaembo/huntbugs
 
SpotBugs is not meant to compete with FindBugs. It was meant to be a last resort to continue FindBugs in Bill's absence, since he has all the admin rights and the trademark. If he is indeed back, that's great! In that case, SpotBugs will likely be stillborn, and everyone will be happy.
HuntBugs is a competitor, re-implementing the FindBugs checks based on a different library, which the author finds easier to work with. I haven't investigated it myself, partly because I only learned of it recently, and partly because my own interest is less about writing detectors, and more about dogfooding.
> Futhermore Bill Pugh is back
That's fantastic to hear, and I'm a little disappointed at the negative reactions posted at that link. Yes, I think it would be beneficial for everyone (including Bill) to have another admin, but he doesn't have to. Even if he actually wanted to keep it to himself, which I think he doesn't, he would be entitled to do that (the copyright licence is permissive, but there's a trademark on the FindBugs name). It's not right, IMO, to take him to task over it.

    On Tuesday, 8 November 2016, 2:15, Reto Merz <reto.merz at gmail.com> wrote:
 

 Hello,

I'm the author of FindBugs-IDEA ( https://plugins.jetbrains.com/plugin/3847 ).
We have 9'000-11'000 downloads per month. It is one of the top plugins with >500'000 downloads.
Our company still use FindBugs and we have also written a custom plugin (like find-sec-bugs, but it is closed-source).
Some of our custom detectors are "mandatory". So the devs are not allowed to check-in code when these detectors report a problem.
Our company is working on a large mission critical project in the financial sector.
Source-code based analysis (like IDEA inspections and PMD) are great and we also use them
but bytecode-based analysis is a must-have for large and complex projects.
We always favor bytecode analysis over source-based because it is much more stable and we can also scan closed-source/obfuscated 3th party libs.
We have also written a custom bytecode analysis tool (ASM-based) because we reach some limitations with FindBugs (but it is also closed-source).


Futhermore Bill Pugh is back
  https://news.ycombinator.com/item?id=12886665

Basically I like the idea of a new, modern bytecode anaysis framework.

Maybe it would be a good choice to use fernflower ( https://github.com/fesh0r/fernflower ) as a base instead of BCEL or procyon.
Fernflower is JetBrains IDEA built-in decompiler and actively maintained.

For us FindBugs has following major problems:

1.
There are no incremental scans/caches. Our company works with a large code base (~470MB compiled .class files without 3th party)
so it is very uncool to re-scan always everything even if only a few classes are changed.
This can be optimized with a inmemory or persistent canonical results/caches.
Well, this is not trivial to support (but definitely not rocket science)
but I think this is worth it and would be a big step in the right direction.
This would allow to do real-time (more or less) analysis while coding within the IDE.

2.
A detector checks multiple bug patterns. This is something a user does not understand.
It is easy to enable/disable a detector but not to deactivate (or exclude) a specific bug pattern.
For example the detector "DumbMethods" is one big monster.
It would be better if the user only cares about "bug patterns".

3.
The descriptions of detectors/bug patterns are partially very stupid.
For example the one of DMI_DOH ( http://findbugs.sourceforge.net/bugDescriptions.html#DMI_DOH ).
In our company we have a QS comitee which decide which detectors/bug patterns are important and must be fixed before commit.
But to declare a detector as important, the comitee needs to understand what the detectors exactly does.
So what we have done is that we had to review the source code of the detectors to find out, what the detectors really does.

4.
The ranking system is weird and not transparent or documented (point 3.).
Some detectors dynamically increment the severity of their "base priority".
The ranking system should be very simple.
We like it how it is done by JetBrains IDEA Inspections.

5.
Detectors have hardcoded options. For example "com/google/common/base/Preconditions" is hard-coded in detector "DumbMethods".
Also here we like how it is done by JetBrains IDEA Inspections. Some inspection have options.
For example the IDEA inspection "@NotNull/@Nullable problems" gives some switches and it also
possible to specifiy N custom @Nonnull annotations (f. e. these from the checkerframework http://types.cs.washington.edu/checker-framework/ )


Then there are some technical issues with FindBugs:
  A. The FindBugs code base is "outdated" and messy.
  B. FindBugs uses static stuff which makes it hard to run multiple different analysis concurrently within same JVM.


It would be great if FindBugs (or a reboot of it) will solve these issue someday in the future.
And I hope SportBugs, HuntBugs and FindBugs does not split the community.


Thanks

_______________________________________________
Findbugs-discuss mailing list
Findbugs-discuss at cs.umd.edu
https://mailman.cs.umd.edu/mailman/listinfo/findbugs-discuss

   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.cs.umd.edu/pipermail/findbugs-discuss/attachments/20161108/6f774b5f/attachment.html>


More information about the Findbugs-discuss mailing list