Top Worst Java Errors
I’ve had my fair share of Java bugs. There is a stage in a programmer’s career that he or she either knows that they rather manage a convenience store or that they can debug common Java errors just by the way the code smells. Here are my list of worst common Java bugs I have been frustrated to solve. These issues have come up more than once, most often in code that I inherited, and had to fix under a time crunch or tight deadline.
mkdir
I’ve had to fix a few bugs related to the mkdir() method in the File class. The mkdir() method creates or makes a new directory. The mkdir() method only creates one directory. But in many situations, especially if the end user is supplying the path of the directory to be created, you will need to crate a whole new directory hierarchy. Often times you will create a directory and subdirectories at one time. In these situations, you want to use the mkdirs() method instead.
Index Of
Most software bugs are caused by assumptions made by the programmer. One common assumption I see developers making is that file names have only one period to separate the file name from the file extension. It is common to see code that finds the first period and everything after that period is assumed to be the extension. Other assumptions regarding file names include that extensions are three characters long or that the file name does not have special characters. The following code snippet is a dramatization of code I have seen in the field, which incorrectly tries parse the file extension.
String filename = "a.file.path.ext";
int index = filename.indexOf(".");
String extension = filename.substring(index);
A different approach, which would have the desired result is to use the lastIndexOf() instead.
Null Equals
I’ve seen a whole slew of null pointer exceptions due to this sort of Java bug where a possibly null object reference will be used to check the equality of a hard coded constant. Here is the code snippet of what I mean.
boolean equals = maybeNullObjectReference.equals("CONSTANT");
The object reference may be null, so you need to check for null values. I found that if you switch your thinking, you can write less code and still achieve a better solution that having to constantly check if the object is null. A safe approach is to use a object that you know is not null, the constant value.
boolean equals = "CONSTANT".equals(maybeNullObjectReference);
Equals
Yet another Java bug that can be easy to miss is the use of the Java equals operator instead of the equals() method. The equals operator returns true if the two object references you are testing point to the same object instance. The equals operator compares the equality of the object references, not the object values but since it reads the same it is easy to overlook.
Map Key
The worst Java bug that I had to ever deal with involved the use of mutable objects as keys in hash maps. The implementation of the Java HashMap is really simple, the hash code of the key is used to locate the bucket in which to store the map entry, which consists of the key/value pair. Once you put a key/value pair in a hash map you should not change the value of the key, ever, in any way that changes the hash code. If the key is changed where it generates a new hash code, you will not be able to locate the correct bucket in the HashMap that contains the key/value pair. I had a scenario where key/value pairs were stored in a HashMap, then the keys where updated generating a new hash code, and there after the value was not able to located.