Two people sent me this code blooper the other day, again, class and parameter names have been changed to protect the identity of the offender(s).

public SomeObject(
boolean lowSetting,
boolean highSetting,
boolean currentSetting,
Color lowColor,
Color highColor,
Color currentColor,
Color otherColor)
{
   super();
   lowSetting     = this.lowSetting;
   highSetting    = this.highSetting;
   currentSetting= this.currentSetting;
   lowColor        = this.lowColor;
   highColor       = this.highColor;
   currentColor   = this.currentColor;
   otherColor      = this.otherColor;
}

I have to admit I didn’t get it in the first couple of second, but it should be clear that this constructor is basically not doing anything. It basically overrides the constructor parameters with the current values in the object, which is more than likely not what we want to do.

BTW it also has a pet peeve of mine, it calls “super()” (the parent’s public no arg constructor). A lot of people don’t know that this is done automatically for you, no need to write code to for it.

Anyways, this one could have been prevented if you had a policy saying that method parameters should be named differently from class members. However, I personally like naming them the same. I guess it shouldn’t be unreasonable for the compiler to give you a warning when you do this, I’m going to guess most of the time you don’t want to do this.

This one is fairly easy to catch, but it was a self inflicted code blooper that had me thinking for a bit.

public class Key implements java.io.Serializable
{
  String key;

  public Key(String key)
  {
    this.key = key;
  }

  @Override
  public String toString()
  {
    return key;
  }

  @Override
   public int hashCode()
   {
      super.hashCode();
   }

   @Override
   @SuppressWarnings("unchecked")
   public boolean equals(Object obj)
   {
       boolean retval = false;

       if (obj != null && getClass() == obj.getClass())
       {
         Key other = (Key)obj;
         retval = other.getKey().equals(getKey());
       }

      return retval;
   }
}

I used this class as a key into a Map. We would send this map over a serialized stream, and on the other side we couldn’t get the values by using the same keys (the keys are static finals/constants).

See if you can spot the error … it’s a bit obvious …

OK, you found it.

Yeah, it’s the hashCode(). You probably know about the equals()/hashCode() rule when using Maps.
Don’t know how that “super” got in there, but that was the problem. Simple of course. As a side note, I’ve been using Netbeans 6 and it has some interesting suggestions for genearting your equals and hashCode() methods. On the equals, I was a bit surprised to see it was using “getClass() == obj.getClass()“, I thought it would do “getClass().equals(obj.getClass())“, just because when I compare non primitive types I’m used to using the equals() method. Somehow this works, I guess because class definitions are loaded once? Intuitively I feel this is not the right way, but it works and seems to be accepted convention.

To be quite honest, I’ve been using “instanceof” for the longest time, and up until recently I didn’t know there was a debate about that one.

Today’s code blooper involves a Java object that cannot be instantiated in Java.

I was helping somebody unit test some code and we kept getting a null pointer exception on the constructor. First of all, the object in question had overly complicated constructors. Imagine something like this.

public FruitBasket(){

// Does nothing important
}

public FruitBasket(String ownerName, Fruit[] fruits, Color color, String brand, Date purchaseDate, boolean hasLid, boolean hasHandles, boolean hasLock, int maxFruits, int width, int height) {

// Copies all values, and copies array to a local array (does not keep reference to one in parameters)

}

Now imagine that constructor has 12-14 parameters, and 1 more constructor. It’s begging for some factory, or heck, just using an empty constructor and rely on “set” methods. Anyways, the thing was blowing up in the constructor and it was hard to see why. It was when it was copying the array to the array in the object. After a bit of debugging I noticed that the array was never initialized, so it was trying to reference a null array. Doh! OK, but this code runs in a real product, how could this work at all?

The answer? JNI. The object in question usually gets created by a JNI program. The array is created in the JNI code, which has full access to the Java private fields, so it’s not a problem. The irony is that without fixing this class, it can never be created in Java. I thought that was a bit ironic, but what this really shows is that this class is lacking basic unit testing in the first place. During integration test, you won’t see these problems because every bit of the application is doing its job. But when you apply unit tests, you tend to catch things like … not being able to instantiate the class!

The bug is a common mistake, but the biggest problems are having multiple constructors share zero code, long constructors that are only large because people keep adding features, and zero unit testing for core classes that are used all over the place.

This is the first entry on a category I’d like to name “Code bloopers”. I recently got a message about a piece of code that was throwing a null pointer, it was basically of this form:

synchronized(this.foobar)

This is an easy one. If you think it’s because “this” is null, you have to go back to programming 101 and don’t collect $200 if you pass Go. I don’t want to sound mean, but yes, this is one of those bloopers that if you get it wrong, I hope it’s because you are half asleep or on drugs.

Remember kids, this can’t be null. In case you have been a victim of this code blooper, don’t feel bad, you are not the only one confused by this. It’s the only case (that I could find in the internet) of somebody else thinking this can be null, and I hope that gives you some comfort.