Java AntiPatterns

Null returned from a method returning a collection or an array

Alex — Wed, 11 Nov 2009 17:10:10 +0000

Null should never be returned from a method returning a collection or an array. Instead return a empty array (a static final empty array) or one of the empty collections (e.g. Collections.EMPTY_LIST assuming the client should not be modifying the collection).

(submitted by Rand McNeely)

Unneccessary thread safety of StringBuffer

Alex — Fri, 22 Aug 2008 04:07:04 +0000

Use StringBuilder rather then StringBuffer, unless synchronization is required. StringBuilder is not thread safe, and therefore avoids the synchronization overhead of StringBuffer.

(submitted by Robert J. Walker)

Comparing URLs with ‘URL.equals()’

Alex — Sat, 24 Nov 2007 06:53:35 +0000

Implementation of equals() in java.net.URL is based on a fancy rule saying that URLs of two hosts are equal as long as they are resolving to the same IP address. It is known to be incompatible with virtual hosting and should not be used.

For instance, URL.equals() would consider the URL of this blog (http://javaantipatterns.wordpress.com) to be equal to an URL of any random blog hosted on WordPress – that is obviously not true.

It is recommended to use java.net.URI objects instead.

P.S.
java.net.URL class is an absolute champion in a number of implemented antipatterns of equals() (and hashCode() as well):

It lies
It is incostistent
It is slow and breakable

‘equals()’ and ‘hashCode()’ are context-sensitive

Alex — Sat, 24 Nov 2007 06:20:43 +0000

equals() and hashCode() implementations should rely only on an internal object state. Making them dependent on other objects, context of use and other external conditions conflicts with the general contracts of consistency:

“For any reference values x and y, multiple invocations of x.equals(y) consistently return true or consistently return false” [*]

“Whenever it is invoked on the same object more than once during an execution of a Java application, the hashCode method must consistently return the same integer” [*]

Violating those contracts may cause all kinds of weird and unpredictable behavior.

A known example of this antipattern is equals() and hashCode() in java.net.URL implementation where they are depending on information returned by a domain name server, rather than on actual stored URL data.

Not taking advantage of ‘toString()’

Alex — Thu, 22 Nov 2007 23:16:50 +0000

Overriding toString() method gives you a cheap way to provide human-readable labels for objects in output. When the objects are used in GUI containers, such as JLists or JTables, it allows to use the default models and renderers instead of writing the custom ones.

Bad:

System.out.println("Author: "+person.getName());

Good:

class Person {
    ...
    public String toString() {
        return this.getName();
    }
}
...
System.out.println("Author: "+person);

Instatiation of immutable objects

Alex — Thu, 22 Nov 2007 15:14:42 +0000

Creating new instances of immutable primitive type wrappers (such as Number subclasses and Booleans) wastes the memory and time needed for allocating new objects. Static valueOf() method works much faster than a constructor and saves the memory, as it caches frequently used instances.

It is guaranteed that two Boolean instances and Integers between -128 and 127 to be pre-cached, thus you definitely should not use the constructor to instantiate them.

Bad:

Integer i = new Integer(0);
Boolean b = new Boolean(true);

Good:

Integer i = Integer.valueOf(0);
Boolean b = Boolean.valueOf(true); // or Boolean.TRUE

Unbuffered I/O

Alex — Thu, 22 Nov 2007 14:41:04 +0000

Reading and writing I/O streams byte-by-byte is too expensive, as every read()/write() call refers to the underlying native (JNI) I/O subsystem. Usage of buffered streams reduces the number of native calls and improves I/O performance considerably.

Bad:

InputStream in = new FileInputStream(f); 
int b; 
while ((b = in.read()) != -1) {    
    ... 
}

Good:

InputStream in = new BufferedInputStream(new FileInputStream(f));
...

‘equals()’ does not check for null argument

Alex — Thu, 22 Nov 2007 14:08:35 +0000

If you override equals() method in your class, always check if an argument is null. If a null value is passed, equals() must unconditionally return false (no NullPointerException should be thrown!).

Bad:

class Person {
    ...
    public boolean equals(Object o) {
        return (o instanceof Person) && 
               this.getName().equals(((Person)o).getName());
    }
    ...
}

Good:

class Person {
    ...
    public boolean equals(Object o) {
        return (o != null) && 
               (o instanceof Person) && 
               this.getName().equals(((Person)o).getName());
    }
    ...
}

‘compareTo()’ is incompatible with ‘equals()’

Alex — Thu, 22 Nov 2007 13:53:39 +0000

If a class implements Comparable, compareTo() method must return zero if and only if equals() returns true for the same non-null argument (and vice versa). Violating this rule may cause unexpected behavior of the objects.

class Product implements Comparable
    ...
    public int compareTo(Object o) {
        if (o == null)
            throw new NullPointerException();
        if (this.equals(o))
            return 0;
        ...    
    }
}

LinkedLists as arrays

Alex — Thu, 22 Nov 2007 13:03:06 +0000

java.util.LinkedList is a special type of collection designed for sequential access (stacks and queues). Being used as a random-accesed array, it is much slower than other List implementations. For instance, getting an item by index (get(n)) has constant complexity O(1) for ArrayLists, while for LinkedList, the complexity of that operation is O(n).

Use ArrayList (or Vector if synchronization is required) for random-accessed lists.