Contracts on java.lang.Object

Explicit calls to finalize()

finalize() must never be called directly, it is to be invoked by the Java VM only. See the Sun API documentation for details.

Solution: remove the call, and consider refactoring the finalize method by moving out code that releases resources into a seperate method.

Severity level: 1

Overriding clone without implementing Cloneable

The contract for the clone method requires that the implementing class implement the java.lang.Cloneable interface, but it doesn't.

Solution: make the class implement java.lang.Cloneable

Severity level: 1

Clone implementation uses Constructor

The clone method is not marked as final, and the implementation uses a constructor call instead of calling super.clone() for the object allocation. If subclasses redefine the clone method then the clone contract will be violated.

Solution: Use super.clone() for the object allocation, or don't use clone at all to copy an object.

Severity level: 1

Usage of finalize()

Objects should not rely on the finalize() method to free resource, for several reasons:

  • prolongs garbage collection, and delays release of memory
  • holds on to resources for too long, if used as the only means to free resources
  • relies on the garbage collector to kick in before possibly limited resources are exhausted (e.g. file descriptors)
  • finalize is not guaranteed to be called (during a VM shutdown, for example)

Solution: consider refactoring the finalize method by moving out code that releases resources into a seperate method.

Severity level: 2

Empty finalize() method

When overriding finalize, superclasses should be given the opportunity to clean up as well, by calling super.finalize().

Solution: remove the overriding method

Severity level: 2

Using equals() on Arrays

The equals() method on array types tests identity only, in most cases the intent is to test if both arrays contain the same element.

Solution: Use the method equals defined in java.util.Arrays for this purpose.

Severity level: 2

The methods hashCode and equals are not both overridden in a type

The methods equals and hashCode generally should be defined in the same class to comply with the requirements stated in the hashCode documentation. If the implementation doesn't fulfill the contract it can't be used as a key in HashMaps.

Solution: implement the contract.

Severity level: 3