JavaAntiPatterns

Collection of bad coding practices

Posts Tagged ‘object

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

with 3 comments

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.

See also:

Written by Alex

November 24, 2007 at 6:20 am

Posted in Objects

Tagged with , ,

Not taking advantage of ‘toString()’

with 2 comments

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.

Read the rest of this entry »

Written by Alex

November 22, 2007 at 11:16 pm

Posted in Objects, Strings

Tagged with ,

Instatiation of immutable objects

with 2 comments

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.

Read the rest of this entry »

Written by Alex

November 22, 2007 at 3:14 pm

Posted in Objects

Tagged with ,

‘equals()’ does not check for null argument

with 7 comments

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!).

Read the rest of this entry »

Written by Alex

November 22, 2007 at 2:08 pm

Posted in Objects

Tagged with , ,

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

with one comment

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.

Read the rest of this entry »

Written by Alex

November 22, 2007 at 1:53 pm

Posted in Objects

Tagged with , ,

‘equals()’ is overridden while ‘hashCode()’ is not

with 5 comments

If you override equals() in your class, always provide a custom implementation of hashCode() that returns the same hash code value for two or more equal objects:

a.equals(b) → a.hashCode() == b.hashCode()

This is, in fact, a general contract defined by Java API Specification. Violation of this rule (which is likely the case if equals() method is overridden while hashCode() is inherited from Object) may cause numerous bugs and unexpected behaviours.

Note that the reverse rule: two or more unequal objects must have different hash codes, or

!a.equals(b) → a.hashCode() != b.hashCode()

though not required, is also highly recommended to be maintained wherever possible (except for the cases when a number of class instances is known to be greater than Integer.MAX_VALUE). Disregard of this rule (hash collisions) may reduce performance of HashMaps and Hashtables.

Read the rest of this entry »

Written by Alex

November 22, 2007 at 8:37 am

Posted in Objects

Tagged with , ,