Dm: Method invokes System.exit(...)
Invoking System.exit shuts down the entire Java virtual machine. This should only been done when it is appropriate. Such calls make it hard or impossible for your code to be invoked by other code. Consider throwing a RuntimeException instead.
EC: Call to equals() with null argument
This method calls equals(Object), passing a null value as the argument. According to the contract of the equals() method, this call should always return false.
EC: Call to equals() comparing different interface types
This method calls equals(Object) on two references of unrelated
interface types (neither is a subtype of the other). According to the contract of equals(), objects of different classes should always
compare as unequal. Note that it is possible that the program contains classes that implement both interfaces, so the comparison may be valid. However, it is worth inspecting closely.
EC: Call to equals() comparing different types
This method calls equals(Object) on two references of different types. According to the contract of equals(), objects of different classes should always compare as unequal; therefore, it is likely that the result of this comparision will always be false at runtime.
ES: Comparison of String objects using == or !=
This code compares java.lang.String objects for reference equality using the == or != operators. Unless both strings are either constants in a source file, or have been interned using the String.intern() method, the same string value may be represented by two different String objects. Consider using the equals(Object) method instead.
Eq: Covariant equals() method defined
This class defines a covariant version of equals(). To correctly
override the equals() method in java.lang.Object, the parameter of equals() must have type java.lang.Object.
Eq: Covariant equals() method defined, Object.equals(Object)
inherited
This class defines a covariant version of the equals() method, but calls the normal equals(Object) method defined in the base java.lang.Object class. The class should probably define a non-covariant version of equals(). (I.e., a method with the signature boolean equals(java.lang.Object).
FI: Explicit invocation of finalizer
This method contains an explicit invocation of the finalize() method on an object. Because finalizer methods are supposed to be executed once, and only by the VM, this is a bad idea.
FI: Finalizer does not call superclass finalizer
This finalize() method does not make a call to its superclass's finalize() method. So, any finalizer actions defined for the superclass will not be performed. Add a call to super.finalize().
FI: Finalizer nullifies superclass finalizer
This empty finalize() method explicitly negates the effect of any
finalizer defined by its superclass. Any finalizer actions defined for the superclass will not be performed. Unless this is intended, delete this method.
HE: Class defines equals() but not hashCode()
This class overrides equals(Object), but does not override
hashCode(). Therefore, the class may violate the invariant that equal objects must have equal hashcodes.
HE: Class defines equals() and uses Object.hashCode()
This class overrides equals(Object), but does not override hashCode(), and inherits the implementation of hashCode() from java.lang.Object (which returns the identity hash code, an arbitrary value assigned to the
object by the VM). Therefore, the class is very likely to violate the invariant that equal objects must have equal hashcodes.
If you don't want to define a hashCode method, and/or don't believe the object will ever be put into a HashMap/Hashtable, define the hashCode() method to throw UnsupportedOperationException.
HE: Class defines hashCode() but not equals()
This class defines a hashCode() method but not an equals()
method. Therefore, the class may violate the invariant that equal objects must have equal hashcodes.
HE: Class defines hashCode() and uses Object.equals()
This class defines a hashCode() method but inherits its equals() method from java.lang.Object (which defines equality by comparing object
references). Although this will probably satisfy the contract that equal objects must have equal hashcodes, it is probably not what was intended by overriding the hashCode() method. (Overriding hashCode() implies that the object's identity is based on criteria more complicated than simple reference equality.)
HE: Class inherits equals() and uses Object.hashCode()
This class inherits equals(Object) from an abstract superclass, and hashCode() from from java.lang.Object (which returns the identity hash
code, an arbitrary value assigned to the object by the VM). Therefore, the class is very likely to violate the invariant that equal objects must have equal hashcodes.
If you don't want to define a hashCode method, and/or don't believe the object will ever be put into a HashMap/Hashtable, define the hashCode() method to throw UnsupportedOperationException.
IC: Initialization circularity
A circularity was detected in the static initializers of the two classes referenced by the bug instance. Many kinds of unexpected behavior may arise from such circularity.
IJU: TestCase implements setUp but doesn't call super.setUp()
Class is a JUnit TestCase and implements the setUp method. The setUp method should call super.setUp(), but doesn't.
IMSE: Dubious catching of IllegalMonitorStateException
IllegalMonitorStateException is generally only thrown in case of a design flaw in your code (calling wait or notify on an object you do not hold a lock on).
It: Iterator next() method can't throw NoSuchElement exception
This class implements the java.util.Iterator interface. However, its next() method is not capable of throwing
java.util.NoSuchElementException. The next() method should be changed so it throws NoSuchElementException if is called when there are no more elements to return.
MF: Class defines field that obscures a superclass field
This class defines a field with the same name as a visible instance field in a superclass. This is confusing, and may indicate an error if methods update or access one of the fields when they wanted the other.
MF: Method defines a variable that obscures a field
This method defines a local variable with the same name as a field in this class or a superclass. This may cause the method to read an
uninitialized value from the field, leave the field uninitialized, or both.
MWN: Mismatched notify()
This method calls Object.notify() or Object.notifyAll() without obviously holding a lock on the object. Calling notify() or notifyAll() without a lock held will result in an IllegalMonitorStateException being thrown.
MWN: Mismatched wait()
This method calls Object.wait() without obviously holding a lock on the object. Calling wait() without a lock held will result in an IllegalMonitorStateException being thrown.
NP: Null pointer dereference in method
A null pointer is dereferenced here. This will lead to a NullPointerException when the code is executed.
NP: Null pointer dereference in method on exception path
A pointer which is null on an exception path is dereferenced here. This will lead to a NullPointerException when the code is executed. Note that because FindBugs currently does not prune
infeasible exception paths, this may be a false warning.
Also note that FindBugs considers the default case of a switch statement to be an exception path, since the default case is often infeasible.
NP: Possible null pointer dereference in method
A reference value dereferenced here might be null at runtime. This may lead to a NullPointerException when the code is executed.
NP: Possible null pointer dereference in method on exception path
A reference value which is null on some exception control path is
dereferenced here. This may lead to a NullPointerException when the code is executed. Note that because FindBugs currently does not prune infeasible exception paths, this may be a false warning.
Also note that FindBugs considers the default case of a switch
statement to be an exception path, since the default case is often infeasible.
NS: Questionable use of non-short-circuit logic
This code seems to be using non-short-circuit logic (e.g., & or |) rather than short-circuit logic (&& or ||). Non-short-circuit logic causes both sides of the expression to be evaluated even when the result can be inferred from knowing the left-hand side. This can be less efficient and can result in errors if the left-hand side guards cases when evaluating the right-hand side can generate an error.
Nm: Class defines equal(); should it be equals()?
This class defines a method equal(Object). This method does not override the equals(Object) method in java.lang.Object, which is probably what was intended.
Nm: Confusing method names
The referenced methods have names that differ only by capitalization.
Nm: Confusing method name
This method has the same name as the superclass of the class it is