Juixe Techknow

We all have heard of missiles blowing up in midair because of the wrong unit was used in calculating the trajectory or bank software that misplaced millions of dollars because of a decimal place. It might not compare against blowing up a multi-million dollar missile but here are some of the worst software bugs I’ve seen in projects where I’ve worked.

Shift + O Short Cut – I once worked on a software application where one of the engineers developed a screen search functionality that would find the UI screen by name or feature. Needless to say the modal pop-up dialog for this search feature popped up when the user hit the Shift + O keys. This feature was developed by the engineer on his own initiative, so you can imagine everyone’s surprised when we couldn’t even type a capital o without this thing popping up.

Exposing Regular Expressions – In another project we developed micro expression language which was used and exposed at the application level to users. In one situation, a user reported a error when he wanted to replace a variable place holder with a dollar amount. It seems that when he called the expression language replaceall(“AMOUNT_VALUE”, “$0.00”) the got back the value of AMOUNT_VALUE.00. This problem was caused because we used Java Regular Expressions feature of the String class and $0 expression is a special value in the Java RegEx. This was like a Regular Expression Injection bug.

Localization and Internationalization – In the same project we had a problem with displaying the correct currency symbol used in a financial account statement. There is a big difference between $100 and €100. Account holders are not happy to know that their €100 are now worth $100.

Cut/Copy/Paste Does Not Work – I have seen way too many Java/Swing application where some component does not have proper support for cut, copy, or paste. When you cut from a Java application and paste to say Notepad you get a stringified Java object.

Textarea Size Limit – When filling online forms, the one bug that just kills me is where a textarea has a size limit not shown and you spend time typing a long response which will be either truncated, lost, or rejected on submit.

ClassCastException – The most common reason for getting a ClassCastException is because the code in question is accessing an object from a List or Map and casting to an particular class, but the List or Map may have different types of classes. If you are not using generics and allow your List to contain any Object, instead of a specific class type, you’ll get a ClassCastException when you force a cast to one type but the object doesn’t descend from that class. A common fix is use Java generics or to check the type of a class before you force the case using the instanceof operator.

InvalidClassVersion – I’ve seen this exception often when working in a client-server environment. This exception is throw when you have two version of the same class in an environment. For example, maybe you made a large change and recompiled a particular class but only updated the server, the client still has a copy of an much older copy of the class. If objects of this class are serialized and shared between the client and the server you’ll an InvalidClassVersion exception. If a server sends a instance of a class to the client, the client who has an older copy of the class, will throw an InvalidClassVersion error because it’s version of the class may not have the newer methods, method signatures, fields, etc. The client version of the class is simply not compatible with the one in the server. To fix this, make sure that same version of any class is always used.

UnsupportedClassVersionError (Unsupported major.minor version 49.0) – This can happen when you compile an application in a higher version of Java then the version of the Java Virtual Machine in which you run the application. For example, if you compile your application for Java 6 but run the application using Java 1.4.2 you will get an UnsupportedClassVersionError.

NoSuchFieldException – A friend from school just sent me a message as to how to fix a NoSuchFieldException. I thought, just double check the library version, that JavaDocs, the source code, and anything else you can to verify that the field does exist in the class. This exception is thrown because he might be using reflection or some dynamic scripting language such as Groovy or JRuby and has misspelled the name of the field he is trying to invoke. The fix is to double check the API.

NoSuchMethodException – This exception is similar to NoSuchFieldException. You’ll see this exception when working with a dynamic language or when using reflection. When you use Java in a dynamic fashion, such as with Groovy or Java reflection, you don’t get the benefits of static compiled language features. You’ll get errors like NoSuchMethodException at run time instead of catching the error at compile time. It is often caused because you mistyped the name of a function that you want to use.

ClassNotFoundException – This exception can happen because you trying to run a class that references another class that is not in the classpath. Check the classpath and make sure that you have the classes and jars you need for you application to run. ClassNotFoundException often happens when you use third party libraries than themselves require other libraries or jars that you are unaware of.

NullPointerException – A typical Java NullPointerExeption is generally easy to fix with a stack trace of the exception. There is only one case where it is difficult to spot the source of a NullPointerException. The only NullPointerException that will have you baffled is those caused by auto-boxing, such as when you auto-box an Integer object to a primitive int variable. If the Integer object is null and you auto-box it to a primitive int when passing the object to a method whose parameter is an int, you’ll get NullPointerException. But if you look at the line where the exception is thrown, you’ll see that it takes an int and int primitives don’t throw exceptions, so you’ll be scratching your head in confusion until you realize that the calling method used an null value Integer object.

You’ll always have to deal with memory issues, no matter the programming language. Even with the Java programming language, if the right precautions are not taken, you will have some sort of memory leaks, memory issue, out of memory exception, or heap size problem. I’ve seen two common types of memory issues in every application I’ve worked on.

A common source of memory leaks is global static singleton god object that collects or manages a lot of data, maybe a system cache, object lookup table, service locator, etc. This type of singleton pattern will require other objects to register with it, add themselves to the global pool of objects, but if they are not properly removed, unregistered, when they are no longer needed you will see your memory usage increase over time. I’ve seen this issue when using the callback or listener pattern and the listener object itself holds a lot of other data. This sort of problem is usually relatively easy to identify with a profiler, it will usually be one of the largest objects in your system.

The other, more difficult memory leak to identify, is when you have hundreds of thousands of objects each taking up a reasonable amount of memory. In this case, a single object instance will not take a lot of memory but collectedly the hundreds of thousands of objects can eat up a lot of memory. Here are a few things you can think about when dealing with a small class that spawns thousand of objects…

If you have int types, see if you can change them to short or byte types. Try subclassing if you have any number of properties that most often than not set or are null. Think about lazy loading arrays, lists, and other objects references. If there are many object instances of this class, and any portion of these instances are logically equivalent, think of using the flyweight pattern.

I don’t count my progress by the line of codes but at the same time I don’t take pride by over engineering a solution. Writing code is like writing for a publication, you have to know at what reading level you are writing for. That said, the one type of code statement that gets under my skin is what I call the run-on code statement. A Run-on code statement is one that has multiple method calls in one statement. Here is a made up example of a run-on code statement.

DataManager.getInstance().refreshData(obj.getAsInteger().toString());

In the above run-on code statement there are four method calls. I’ve seen worse. The reason whey run-on code statements are a pet peeve or mine is that if anyone method call fails because of a NullPointerException or some other error it’s difficult to quickly know what segment of the code statement failed. This is also annoying to debug if you want to step into one method out of the four.

Processes are supposed to support people, not people support processes. A process should be documented in one document or checklist or directory or wiki or website that everyone has access to. Everyone should have a copy readily available. It should not be outlined in emails or sporadically over several documents across different locations. Always review the process and remove friction. Try to minimize steps when possible, centralize the information, anoint clear responsibilities, build in safety nets, empower developer to make decisions, let it grow as the team grows. Automate the process as much as you can, make reports people can use, make everyone’s progress visible. For some certain teams, there is diminishing returns for adding more processes.

Even when I have been the sole developer in a class, interface, module, library, or feature I try to always report progress as “We.” For defects and issues it’s always easy to point out the fault and personalize the problem when it was caused by someone else. Avoid naming names or singling out an individual. Saying “Your broke this” doesn’t make you look better or solve the issue. Restate it as “This was broken by this change list you committed on this date while trying to resolve this other issue.” Don’t personalize blame or fault, and provide as much information as you can gather to better solve the issue. Don’t stop when you find something is broken, or when you find who broke it, find out why it was broken in the first place, and if at all possible suggest viable solutions.

A few days ago, a engineer called me over for some help. He immediately started making using accusatory language as if I had committed some crime. “There is a bug and you wrote this so you did it and you didn’t do it well because there is a bug.” He was pointing to 20 lines of code that I had written over a year ago in a much larger feature whose requirements had changed over time and because of his tone and desperation in his voice I could tell he was lost just dropped the anchor of blame wherever he could. I tried to get focus to the task at hand an not my code and asked a series of questions, what does the system do now? What should the system do? Does this always happen? What is unique when there is an error? Using this approach we found the issue in 10 minutes without staring down the code or focusing who wrote what method.