What is going on here?
FindBugs is a development-time tool that finds bugs in Java programs using static analysis. It’s free and distributed under the Lesser GNU Public License out of The University of Maryland. Most developers use FindBugs through Maven and the Maven Findbugs Plugin. David Hovemeyer who did his Ph.D. thesis on FindBugs founded the project. Since then Bill Pugh has been the project lead and primary developer. The current developers listed for FindBugs are Bill Pugh and Andrey Loskutov.
Reviewing Andrey’s November 2nd post (edited in quotes for minor typos and clarity), here what seems to be the Good, the Bad and the Ugly, no not that one, but the film is a classic and the images below are all in good fun.
The Good is thin: FindBugs has two committers with push karma: Andrey Loskutov and Tagir Valeev. That’s not much for such a complex project but better than none. Tagir’s last commit (Google Code Archive) was on 2015-04-09 and Andrey does not consider him active. Andrey has stated that he himself “has no free time to work on the project”. (There is code on the Google Code Archive and then on GitHub.)
Bill Pugh, the project lead, has not been active and is the bottleneck for access rights to critical parts of the project. According to Andrey:
“Only the project leader Bill Pugh has admin rights for the project web page and the GitHub project group and page. We cannot deploy any website update, we can’t add new project members, we can’t manage code access rights, we can’t publish releases to the well-known update sites without his help. Without him, we have no admin rights to anything; we can only push to the repository.”
This seems to be par for the course in many FOSS projects, the benevolent dictator acts as a gatekeeper to resources and once a bus or vacation enters the pictures, this locks out contributors. Bill Pugh, the project lead, has not been active or responsive it seems (until now, more on this later).
FindBugs has been around for a long time now (ten years) and has accrued a fair amount of technical debt.
Andrey states that the code is very complex, has “organically grown” over a decade. Not surprisingly and like many other FOSS projects, and authors have not done much in terms of documentation. Poor public interfaces apparently compound the hurt.
“Most of the code consists of the very low level bytecode related stuff, tightly coupled with the ancient BCEL library, which doesn’t scale and is not multi-thread safe.”
I hear you there. I help out over at Apache Commons, the current home of the Apache Commons BCEL component, where we released in July a long overdue version 6.0. Apache published the previous version 5.2; wait for it… in June 2006! Ouch, FindBugs, I feel your pain. It might be too late for FindBugs and Apache Commons BCEL developers to work together to salvage this dependency:
“No one enjoys maintaining this code, at least not me. I see no future for FindBugs with the BCEL approach, and see no way to get rid of it without investing lot of effort, and without breaking every detector and possibly many third party tools. This is the biggest issue we have with FindBugs today, and most likely the root cause for all the evil. This code can’t be fixed, it must be rewritten.”
What are the alternatives?
Luckily, there are other byte code fiddling tools out there. We have (quoted with minor edits from their respective sites):
- ASM (INRIA, France Telecom license) from the OW2 consortium. ASM is an all-purpose Java bytecode manipulation and analysis framework. You can use ASM to modify existing classes or dynamically generate classes, directly in binary form. ASM provides common transformations and analysis algorithms allow you to assemble easily custom complex transformations and code analysis tools.
- Apache Commons Weaver (Apache 2.0 license) manipulates existing class files. It looks like FINDBUGS has started to work on some integration with ASM based on looking at a few commits.
- Javassist (Mozilla Public License 1.1, LGPL 2.1, Apache 2.0 licenses) is a class library for editing bytecodes in Java; it enables Java programs to define a new class at runtime and to modify a class file when the JVM loads it. Unlike other similar bytecode editors, Javassist provides two levels of API: source level and bytecode level. If the users use the source-level API, they can edit a class file without knowledge of the specifications of the Java bytecode. Javassist designed the whole API with only the vocabulary of the Java language. You can even specify inserted bytecode in the form of source text; Javassist compiles it on the fly. On the other hand, the bytecode-level API allows the users to edit directly a class file as other editors.
- Byte Buddy (Apache 2.0 license) is a code generation and manipulation library for creating and modifying Java classes during the runtime of a Java application and without the help of a compiler. Other than the code generation utilities that ship with the Java Class Library, Byte Buddy allows the creation of arbitrary classes and is not limited to implementing interfaces for the creation of runtime proxies. Furthermore, Byte Buddy offers a convenient API for changing classes either manually, using a Java agent or during a build.
From FindBugs to HuntBugs
Andrey thinks that because the code is as it is, there are not so many people willing to contribute. GitHub sees some pull requests, but most of them are smaller fixes or enhancements which are not reviewed or tested.
These conditions has led Tagir to start his own project called HuntBugs, a new Java bytecode static analyzer tool based on Procyon Compiler Tools aimed to supersede FindBugs. HuntBugs is currently in early development stage and published under the Apache 2.0 license. It also sports seven contributors on GitHub, an almost good sign, but all of these contributors only have a handful of commits each. Almost all commits are from Tagir, so the word “community” seems generous. The Procyon Compiler Tools are published on BitBucket also under the Apache 2.0 license.
The lack of community around FindBugs is what killed it’s momentum. This happens over and over in the FOSS world.
Like many FOSS projects and again to no one’s surprise, there is little support from any companies or organizations. The FindBugs sponsors page states that the most recent funding for FindBugs comes from a Google Faculty Research Awards. No code patches, no testing, no paid developers. Of course, Andrey remarks, some companies do use FindBugs in commercial products like SonarSource and Coverity, not to mention countless companies using FindBugs in their build processes.
As it is today, even without further development, FindBugs is still useful. Sadly it cannot find bugs that are specific to Java 8 or Java 9’s early releases.
What’s on the horizon?
There are two paths here: FindBugs will raise from its ashes or a fork will take over. There are a number of steps Andrey outlines in his post to allow the current contributors (himself really) to continue the project. These are mostly project governance and access rights issues. However, having stated that his time is limited, does this seem realistic? This assumes that Bill follows the steps to further open up FindBugs and that this will lead to a community forming around a more open FindBugs . Summarizing from Andrey’s post, the following needs to happen:
- Update the site to point to GitHub instead of SourceForge.
- Shut down the old SourceForge bug tracker and forums and point to GitHub instead.
- Allow to grant access rights to the GitHub project.
- Grant right to publish the new releases all known download sites.
- Configure automated build and test (hello Travis CI and Coveralls)
- Attract contributors
None of these seems difficult or insurmountable; it just needs Bill’s blessing and a new project governance model that allows other contributors to come in have proper access rights. Perhaps FindBugs could adopt some of Apache’s nomenclature: You can be a committer with push rights and above that a Project Management Committee (PMC) member, with full access to the project. Only votes from PMC members vote are binding on release votes. This would allow many committers to come in under the mentorship of a PMC.
Then after all this, Bill pops up on Hacker News:
“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 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.
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.”
So that sounds good…
This is all fine and good and I hope that Bill can work with the current contributors, or the one contributor to rejuvenate FindBugs. What Andrey asks sounds reasonable, but that is not enough. I believe that better project governance would really help FindBugs move forward again.
What about bringing FindBugs under the auspices of an Apache top-level project? Bringing a project under the Apache umbrella is done through the Apache Incubator under a well-defined process. This would really deal with all project governance issues and infrastructure in one go. The project sources could still live in GitHub, but the Apache-way of doing things would address many if not all of Andey’s concerns.
What do you think?
Cheers and Happy Coding,