Itâs common for even the best programmers to make simple mistakes. And sometimes a refactoring which seems safe can leave behind code which will never do whatâs intended.
Weâre used to getting help from the compiler, but it doesnât do much beyond static type checking. Using Error Prone to augment the compilerâs type analysis, you can catch more mistakes before they cost you time, or end up as bugs in production. We use Error Prone in Googleâs Java build system to eliminate classes of serious bugs from entering our code, and weâve open-sourced it, so you can too!
Error Prone âŚ
import java.util.Set;
import java.util.HashSet;
public class ShortSet {
public static void main (String[] args) {
Set<Short> s = new HashSet<>();
for (short i = 0; i < 100; i++) {
s.add(i);
s.remove(i - 1);
}
System.out.println(s.size());
}
}
$ bazel build :hello
ERROR: example/myproject/BUILD:29:1: Java compilation in rule '//example/myproject:hello'
ShortSet.java:6: error: [CollectionIncompatibleType] Argument 'i - 1' should not be passed to this method;
its type int is not compatible with its collection's type argument Short
s.remove(i - 1);
^
(see https://errorprone.info/bugpattern/CollectionIncompatibleType)
1 error
Doug Lea, on learning of a bug we discovered in ConcurrentHashMap:
Definitely embarrassing. I guess Iâm back to liking Error Prone even though it sometimes annoys me :-)