Posted in java, Software Engineering

Null Collections – a pitfall for programmers

Null-hostile collections

Many JDK collection types permit null elements:

  • ArrayList
  • LinkedList
  • Hash{Set,Map}
  • LinkedHash{Set,Map}
  • Tree{Set,Map} (with suitable comparator)
  • IdentityHashMap
  • EnumMap (values)
  • CopyOnWriteArray{List,Set}

But many don’t:

  • EnumSet
  • EnumMap (keys)
  • ConcurrentHashMap
  • ConcurrentSkipList{Set,Map}
  • All ten Queue implementations except LinkedList

Likewise in Guava we have many general-purpose collections that permit null:

  • ArrayListMultimap
  • HashBiMap
  • HashMulti{set,map}
  • LinkedHashMulti{set,map}
  • TreeMulti{set,map} (with suitable comparator)
  • LinkedListMultimap
  • MutableClassToInstanceMap
  • HashBasedTable
  • Sets.union/intersection/difference

but many that do not:

  • ConcurrentHashMultiset
  • EnumBiMap
  • EnumMultiset
  • MinMaxPriorityQueue
  • Interners
  • MapMaker-made maps
  • Sets.cartesianProduct/powerSet
  • All implementations of ImmutableCollection and ImmutableMap

But what if?

What if you find yourself wanting to put a null element into one of these null-hostile beasts?

  • If in a Set or as a key in a Map — don’t; it’s clearer (less surprising) if you explicitly special-case null during lookup operations
  • If as a value in a Map — leave out that entry; keep a separate Set of non-null keys (or null keys)
  • If in a List — if the list is sparse, might you rather use a Map<Integer, E>?
  • Consider if there is a natural “null object” that can be used. There isn’t always. But sometimes.
    • example: if it’s an enum, add a constant to mean whatever you’re expecting null to mean here.
  • Just use a different collection implementation, for example Collections.unmodifiableList(Lists.newArrayList()) instead ofImmutableList.
  • Mask the nulls (this needs more detail)
  • Use Optional<T>

how to cope with collections that don’t allow null : ¬†https://code.google.com/p/guava-libraries

Posted in java, Software Engineering

How to override equals and hashCode and What is the effective way to do it?

Before we begin, let’s read something from java Documentation

equals() (javadoc) must define an equality relation (it must be reflexive, symmetric, and transitive). In addition, it must be consistent (if the objects are not modified, then it must keep returning the same value). Furthermore, o.equals(null) must always return false.

hashCode() (javadoc) must also be consistent (if the object is not modified in terms of equals(), it must keep returning the same value).

The relation between the two methods is:

Whenever a.equals(b), then a.hashCode() must be same as b.hashCode().
In practice:

If you override one, then you should override the other.

Use the same set of fields that you use to compute equals() to compute hashCode().

Luckily there are the excellent helper classes EqualsBuilder and HashCodeBuilder from the Apache Commons Lang library. An example:

public class Employee {

private String name;

private int age;

// …

public int hashCode() {

return new HashCodeBuilder(17, 31). // two randomly chosen prime numbers

// if deriving: appendSuper(super.hashCode()).

append(name).

append(age).

toHashCode();

}

public boolean equals(Object obj) {

if (!(obj instanceof Employee))

return false;

if (obj == this)

return true;

Employee rhs = (Employee) obj;

return new EqualsBuilder().

// if deriving: appendSuper(super.equals(obj)).

append(name, rhs.name).

append(age, rhs.age).

isEquals();

}

}

Also remember:

When using a hash-based Collection or Map such as HashSet, LinkedHashSet, HashMap, Hashtable, or WeakHashMap, make sure that the hashCode() of the key objects that you put into the collection never changes while the object is in the collection. The bulletproof way to ensure this is to make your keys immutable, which has also other benefits.