Bugs found in HBase 2.0:

Bugs found in HBase 2.0:

Pattern: Call to equals() comparing different types

id: EC_UNRELATED_TYPES, type: EC, category:CORRECTNESS

This method calls equals(Object) on two references of different class typeswith no common subclasses. Therefore, the objects being compared are unlikelyto be members of the same class at runtime (unless some application classeswere not analyzed, or dynamic class loading can occur at runtime). According tothe contract of equals(), objects of different classes should always compare asunequal; therefore, according to the contract defined byjava.lang.Object.equals(Object), the result of this comparison will always befalse at runtime.

 

Pattern: Class defines compareTo(...) and usesObject.equals()

id: EQ_COMPARETO_USE_OBJECT_EQUALS, type: Eq, category:BAD_PRACTICE

This class defines a compareTo(...) method but inherits its equals()method from java.lang.Object. Generally, the value of compareTo should returnzero if and only if equals returns true. If this is violated, weird andunpredictable failures will occur in classes such as PriorityQueue. In Java 5the PriorityQueue.remove method uses the compareTo method, while in Java 6 ituses the equals method.

From the JavaDoc for the compareTo method in the Comparable interface:

It is strongly recommended, but not strictly requiredthat (x.compareTo(y)==0) == (x.equals(y)). Generally speaking, any class thatimplements the Comparable interface and violates this condition should clearlyindicate this fact. The recommended language is "Note: this class has anatural ordering that is inconsistent with equals."

 

 

Pattern: Class defines equals() and uses Object.hashCode()

id: HE_EQUALS_USE_HASHCODE, type: HE, category:BAD_PRACTICE

This class overrides equals(Object), but does not override hashCode(), andinherits the implementation of hashCode() from java.lang.Object (which returnsthe identity hash code, an arbitrary value assigned to the object by theVM).  Therefore, the class is very likely to violate the invariant thatequal objects must have equal hashcodes.

If you don't think instances of this class will ever be inserted into aHashMap/HashTable, the recommended hashCode implementation to use is:

public int hashCode() {

  assert false :"hashCode not designed";

  return 42; // anyarbitrary constant will do

  }

Pattern: clone method does not call super.clone()

id: CN_IDIOM_NO_SUPER_CALL, type: CN, category:BAD_PRACTICE

This non-final class defines a clone() method that does not callsuper.clone(). If this class ("A") is extended by a subclass("B"), and the subclass B calls super.clone(), then itis likely that B's clone() method will return an object of type A,which violates the standard contract for clone().

If all clone() methods call super.clone(), then they are guaranteed to useObject.clone(), which always returns an object of the correct type.

 

Pattern: Constructor invokes Thread.start()

id: SC_START_IN_CTOR, type: SC, category:MT_CORRECTNESS

The constructor starts a thread. This is likely to be wrong if the classis ever extended/subclassed, since the thread will be started before thesubclass constructor is started.

 

Pattern: Dead store to local variable

id: DLS_DEAD_LOCAL_STORE, type: DLS, category:STYLE

This instruction assigns a value to a local variable, but the value is notread or used in any subsequent instruction. Often, this indicates an error,because the value computed is never used.

Note that Sun's javac compiler often generates dead stores for final localvariables. Because FindBugs is a bytecode-based tool, there is no easy way toeliminate these false positives.

 

Pattern: equals method always returns false

id: EQ_ALWAYS_FALSE, type: Eq, category:CORRECTNESS

This class defines an equals method that always returns false. This meansthat an object is not equal to itself, and it is impossible to create usefulMaps or