Last time we implemented a minimal detector, and I presented the code for the detector as a fait accompli. Let’s take a closer look at it. import java.nio.file.Files; import edu.umd.cs.findbugs.BugInstance; import edu.umd.cs.findbugs.BugReporter; import edu.umd.cs.findbugs.BytecodeScanningDetector; import edu.umd.cs.findbugs.classfile.ClassDescriptor; import edu.umd.cs.findbugs.classfile.DescriptorFactory; import edu.umd.cs.findbugs.classfile.MethodDescriptor; public class FilesLinesDetector extends BytecodeScanningDetector { private static final ClassDescriptor JAVA_NIO_FILES = DescriptorFactory.createClassDescriptor(Files.class); final BugReporter bugReporter; public FilesLinesDetector(final BugReporter bugReporter) { this.bugReporter = bugReporter; } @Override public void sawMethod() { MethodDescriptor invokedMethod = getMethodDescriptorOperand(); ClassDescriptor invokedObject = getClassDescriptorOperand(); if(invokedMethod !

Findbugs is an incredibly powerful tool, and it supports running of custom detectors. However, the API for writing custom detectors is not well documented, at least as far as I’ve been able to find. So, as I started writing detectors, I’ve been working primarily off a process of trial and error. It’s likely there are better ways of doing things: what follows, however, at least works. Let’s start off with something easy: a detector which labels invocations of a method as bugs.

We realised we had a problem when our performance testing environment locked up. Our deployment system wasn’t responding to input, and when we looked at it we had a bunch of exceptions: turns out we were running out of file handles. We’d seen similar situations before when the file handle count was unnecessarily low, but that wasn’t the case here. Fortunately, we re-deploy and run a fresh perf test roughly every 45 minutes, so that narrowed the range of possible commits down significantly.