FindBugs
 
Docs and Info
Fact sheet
Manual (en)
Manual (ja)
FAQ
Bug descriptions
Mailing lists
Documents and Publications
Links
 
Downloads
 
FindBugs Swag
 
Development
Reporting bugs
Contributing
Dev team
Change log
SF project page
Browse source

FindBugs Bug Descriptions

This document lists the standard bug patterns reported by FindBugs version 0.9.1.

Summary

DescriptionCategory
AM: Creates an empty jar file entryCorrectness
AM: Creates an empty zip file entryCorrectness
BC: Impossible castCorrectness
BC: instanceof will always return falseCorrectness
BIT: Incompatible bit masksCorrectness
BIT: Incompatible bit masksCorrectness
BIT: Incompatible bit masksCorrectness
BOA: Class overrides a method implemented in super class Adapter wronglyCorrectness
BRSA: Method attempts to access a result set field with index 0Correctness
CN: Class implements Cloneable but does not define or use clone methodCorrectness
CN: clone method does not call super.clone()Correctness
Co: Abstract class defines covariant compareTo() methodCorrectness
Co: Covariant compareTo() method definedCorrectness
DE: Method might drop exceptionCorrectness
DE: Method might ignore exceptionCorrectness
DLS: Overwritten incrementCorrectness
DMI: Passes a constant value for a month outside of the expected range of 0..11Correctness
DMI: hasNext method invokes nextCorrectness
DMI: Invocation of substring(0), which returns the original valueCorrectness
Dm: Method invokes System.exit(...)Correctness
Dm: Method invokes runFinalizersOnExit, one of the most dangerous methods in the Java libraries. Correctness
EC: Invocation of equals() on an array, which is equivalent to ==Correctness
EC: Call to equals() with null argumentCorrectness
EC: Call to equals() comparing unrelated class and interfaceCorrectness
EC: Call to equals() comparing different interface typesCorrectness
EC: Call to equals() comparing different typesCorrectness
ES: Comparison of String objects using == or !=Correctness
Eq: Abstract class defines covariant equals() methodCorrectness
Eq: Covariant equals() method definedCorrectness
Eq: Covariant equals() method defined, Object.equals(Object) inheritedCorrectness
FE: Test for floating point equality.Correctness
FI: Explicit invocation of finalizerCorrectness
FI: Finalizer does not call superclass finalizerCorrectness
FI: Finalizer nullifies superclass finalizerCorrectness
HE: Class defines equals() but not hashCode()Correctness
HE: Class defines equals() and uses Object.hashCode()Correctness
HE: Class defines hashCode() but not equals()Correctness
HE: Class defines hashCode() and uses Object.equals()Correctness
HE: Class inherits equals() and uses Object.hashCode()Correctness
IC: Initialization circularityCorrectness
ICAST: Integer shift by an amount not in the range 0..31Correctness
ICAST: Integer division result cast to doubleCorrectness
ICAST: Integer value cast to double and then passed to Math.ceilCorrectness
IJU: TestCase implements setUp but doesn't call super.setUp()Correctness
IJU: TestCase implements a suite method, but this method is not static and should beCorrectness
IJU: TestCase implements tearDown but doesn't call super.tearDown()Correctness
IL: A container is added to itself.Correctness
IL: An apparent infinite recursive loop.Correctness
IM: Integer multiply of result of integer remainderCorrectness
IMSE: Dubious catching of IllegalMonitorStateExceptionCorrectness
IP: A parameter is dead upon entry to a method but overwrittenCorrectness
ISC: Needless instantiation of class that only supplies static methodsCorrectness
It: Iterator next() method can't throw NoSuchElement exceptionCorrectness
J2EE: Store of non serializable object into HttpSessionCorrectness
MF: Class defines field that obscures a superclass fieldCorrectness
MF: Method defines a variable that obscures a fieldCorrectness
MWN: Mismatched notify()Correctness
MWN: Mismatched wait()Correctness
NP: Null pointer dereference in methodCorrectness
NP: Null pointer dereference in method on exception pathCorrectness
NP: equals() method does not check for null parameterCorrectness
NP: Immediate dereference of the result of readLine()Correctness
NP: Method call passes null to a parameter declared @NonNullCorrectness
NP: Method may return null, but is declared @NonNullCorrectness
NP: Possible null pointer dereference in methodCorrectness
NP: Possible null pointer dereference in method on exception pathCorrectness
NP: Possible null pointer returned by method could be dereferenced Correctness
NP: Method call passes null for unconditionally dereferenced parameterCorrectness
NP: Non-virtual method call passes null for unconditionally dereferenced parameterCorrectness
NP: Read of unwritten fieldCorrectness
NS: Questionable use of non-short-circuit logicCorrectness
Nm: Class defines equal(); should it be equals()?Correctness
Nm: Class is not derived from an Exception, even though it is named as suchCorrectness
Nm: Confusing method namesCorrectness
Nm: Class defines hashcode(); should it be hashCode()?Correctness
Nm: Class defines tostring(); should it be toString()?Correctness
Nm: Apparent method/constructor confusionCorrectness
Nm: Very confusing method namesCorrectness
ODR: Method may fail to close database resourceCorrectness
ODR: Method may fail to close database resource on exceptionCorrectness
OS: Method may fail to close streamCorrectness
OS: Method may fail to close stream on exceptionCorrectness
QF: Complicated, subtle or wrong increment in for-loop Correctness
RC: Suspicious reference comparisonCorrectness
RCN: Redundant comparison of non-null value to nullCorrectness
RCN: Redundant comparison of two null valuesCorrectness
RCN: Redundant nullcheck of value known to be nullCorrectness
RCN: Redundant nullcheck of value known to be nullCorrectness
RCN: Nullcheck of value previously dereferencedCorrectness
RE: Invalid syntax for regular expressionCorrectness
RR: Method ignores results of InputStream.read()Correctness
RR: Method ignores results of InputStream.skip()Correctness
RV: Random value from 0 to 1 is coerced to the integer 0Correctness
RV: Method checks to see if result of String.indexOf is positiveCorrectness
RV: Method discards result of readLine after checking if it is nonnullCorrectness
RV: Method ignores return valueCorrectness
SA: Self assignment of fieldCorrectness
SI: Static initializer for class creates instance before all static final fields assignedCorrectness
SIO: Unnecessary type check done using instanceof operatorCorrectness
STI: Unneeded use of currentThread() call, to call interrupted() Correctness
STI: Static Thread.interrupted() method is mistakenly attempted to be called on an arbitrary Thread objectCorrectness
SW: Certain swing methods should only be invoked from the Swing event threadCorrectness
Se: Non-transient non-serializable instance field in serializable classCorrectness
Se: serialVersionUID isn't finalCorrectness
Se: serialVersionUID isn't longCorrectness
Se: serialVersionUID isn't staticCorrectness
Se: Class is Serializable but its superclass doesn't define a void constructorCorrectness
Se: Class is Externalizable but doesn't define a void constructorCorrectness
SnVI: Class is Serializable, but doesn't define serialVersionUIDCorrectness
UCF: Useless control flow in methodCorrectness
UI: Usage of GetResource may be unsafe if class is extendedCorrectness
UR: Uninitialized read of field in constructorCorrectness
UwF: Field only ever set to nullCorrectness
UwF: Unwritten fieldCorrectness
Dm: Method invokes dubious String.toUpperCase() or String.toLowerCase; use the Locale parameterized version insteadInternationalization
EI: Method may expose internal representation by returning reference to mutable objectMalicious code vulnerability
EI2: Method may expose internal representation by incorporating reference to mutable objectMalicious code vulnerability
FI: Finalizer should be protected, not publicMalicious code vulnerability
MS: Method may expose internal static state by storing a mutable object into a static fieldMalicious code vulnerability
MS: Field isn't final and can't be protected from malicious codeMalicious code vulnerability
MS: Public static method may expose internal representation by returning arrayMalicious code vulnerability
MS: Field should be both final and package protectedMalicious code vulnerability
MS: Field is a mutable arrayMalicious code vulnerability
MS: Field is a mutable HashtableMalicious code vulnerability
MS: Field should be moved out of an interface and made package protectedMalicious code vulnerability
MS: Field should be package protectedMalicious code vulnerability
MS: Field isn't final but should beMalicious code vulnerability
DC: Possible double check of fieldMultithreaded correctness
Dm: Monitor wait() called on ConditionMultithreaded correctness
Dm: A thread was created using the default empty run methodMultithreaded correctness
ESync: Empty synchronized blockMultithreaded correctness
IS2: Inconsistent synchronizationMultithreaded correctness
JLM: Synchronization performed on java.util.concurrent Lock in methodMultithreaded correctness
LI: Incorrect lazy initialization of static fieldMultithreaded correctness
ML: Method synchronizes on an updated fieldMultithreaded correctness
NN: Naked notify in methodMultithreaded correctness
No: Using notify() rather than notifyAll() in methodMultithreaded correctness
RS: Class's readObject() method is synchronizedMultithreaded correctness
Ru: Invokes run on a thread (did you mean to start it instead?)Multithreaded correctness
SC: Constructor invokes Thread.start()Multithreaded correctness
SP: Method spins on fieldMultithreaded correctness
SWL: Method calls Thread.sleep() with a lock heldMultithreaded correctness
TLW: Wait with two locks heldMultithreaded correctness
UG: Unsynchronized get method, synchronized set methodMultithreaded correctness
UL: Method does not release lock on all pathsMultithreaded correctness
UL: Method does not release lock on all exception pathsMultithreaded correctness
UW: Unconditional wait in methodMultithreaded correctness
VO: A volatile reference to an array doesn't treat the array elements as volatileMultithreaded correctness
WS: Class's writeObject() method is synchronized but nothing else isMultithreaded correctness
Wa: Condition.await() not in loop in methodMultithreaded correctness
Wa: Wait not in loop in methodMultithreaded correctness
Dm: Method invokes dubious Boolean constructor; use Boolean.valueOf(...) insteadPerformance
Dm: Method allocates a boxed primitive just to call toStringPerformance
Dm: Explicit garbage collection; extremely dubious except in benchmarking codePerformance
Dm: Method allocates an object, only to get the class objectPerformance
Dm: Use the nextInt method of Random rather than nextDouble to generate a random integerPerformance
Dm: Method invokes dubious new String(String) constructor; just use the argumentPerformance
Dm: Method invokes dubious String.equals(""); use String.length() == 0 insteadPerformance
Dm: Method invokes toString() method on a String; just use the StringPerformance
Dm: Method invokes dubious new String() constructor; just use ""Performance
FI: Empty finalizer should be deletedPerformance
FI: Finalizer does nothing but call superclass finalizerPerformance
ITA: Method uses toArray() with zero-length array argumentPerformance
SBSC: Method concatenates strings using + in a loopPerformance
SIC: Should be a static inner classPerformance
SIC: Could be refactored into a named static inner classPerformance
SIC: Could be refactored into a static inner classPerformance
SS: Unread field: should this field be static?Performance
UPM: Private method is never calledPerformance
UrF: Unread fieldPerformance
UuF: Unused fieldPerformance
WMI: Inefficient use of keySet iterator instead of entrySet iteratorPerformance
BC: Questionable cast to abstract collection Style
BC: Questionable cast to concrete collectionStyle
BC: Unchecked/unconfirmed castStyle
BC: instanceof will always return trueStyle
CD: Test for circular dependencies among classes.Style
DB: Method uses the same code for two branchesStyle
DLS: Dead store to local variableStyle
ICAST: Unsigned right shift cast to short/byteStyle
MTIA: Class extends Servlet class and uses instance variables.Style
MTIA: Class extends Struts Action class and uses instance variables.Style
NP: Read of field not initialized in constructorStyle
Nm: Class names should start with an upper case letterStyle
Nm: Field names should start with an lower case letterStyle
Nm: Method names should start with an lower case letterStyle
PS: Class exposes synchronization and semaphores in its public interface.Style
PZLA: Consider returning a zero length array rather than nullStyle
REC: java.lang.Exception is caught when Exception is not thrownStyle
RI: Class implements same interface as superclass.Style
SA: Self assignment of local variableStyle
SF: Switch statement found where one case falls thru to the next caseStyle
ST: Write to static field from instance methodStyle
TEST: TestingStyle
UM: Method calls static Math class method on a constant valueStyle
UwF: Field not initialized in constructorStyle
XFB: Method directly allocates a specific implementation of xml interfacesStyle

Descriptions

AM: Creates an empty jar file entry (AM_CREATES_EMPTY_JAR_FILE_ENTRY)

The code calls putNextEntry(), immediately followed by a call to closeEntry(). This results in an empty JarFile entry. The contents of the entry should be written to the JarFile between the calls to putNextEntry() and closeEntry().

AM: Creates an empty zip file entry (AM_CREATES_EMPTY_ZIP_FILE_ENTRY)

The code calls putNextEntry(), immediately followed by a call to closeEntry(). This results in an empty ZipFile entry. The contents of the entry should be written to the ZipFile between the calls to putNextEntry() and closeEntry().

BC: Impossible cast (BC_IMPOSSIBLE_CAST)

This cast will always throw a ClassCastException.

BC: instanceof will always return false (BC_IMPOSSIBLE_INSTANCEOF)

This instanceof test will always return false. Although this is safe, make sure it isn't an indication of some misunderstanding or some other logic error.

BIT: Incompatible bit masks (BIT_AND)

This method compares an expression of the form (a & C) to D, which will always compare unequal due to the specific values of constants C and D. This may indicate a logic error or typo.

BIT: Incompatible bit masks (BIT_AND_ZZ)

This method compares an expression of the form (a & 0) to 0, which will always compare equal. This may indicate a logic error or typo.

BIT: Incompatible bit masks (BIT_IOR)

This method compares an expression of the form (a | C) to D. which will always compare unequal due to the specific values of constants C and D. This may indicate a logic error or typo.

Typically, this bug occurs because the code wants to perform a membership test in a bit set, but uses the bitwise OR operator ("|") instead of bitwise AND ("&").

BOA: Class overrides a method implemented in super class Adapter wrongly (BOA_BADLY_OVERRIDDEN_ADAPTER)

This method overrides a method found in a parent class, where that class is an Adapter that implements a listener defined in the java.awt.event or javax.swing.event package. As a result, this method will not get called when the event occurs.

BRSA: Method attempts to access a result set field with index 0 (BRSA_BAD_RESULTSET_ACCESS)

A call to getXXX or updateXXX methods of a result set was made where the field index is 0. As ResultSet fields start at index 1, this is always a mistake.

CN: Class implements Cloneable but does not define or use clone method (CN_IDIOM)

Class implements Cloneable but does not define or use the clone method.

CN: clone method does not call super.clone() (CN_IDIOM_NO_SUPER_CALL)

This class defines a clone() method that does not call super.clone(), and is not final. If this class ("A") is extended by a subclass ("B"), and the subclass B calls super.clone(), then it is 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 use Object.clone(), which always returns an object of the correct type.

Co: Abstract class defines covariant compareTo() method (CO_ABSTRACT_SELF)

This class defines a covariant version of compareTo().  To correctly override the compareTo() method in the Comparable interface, the parameter of compareTo() must have type java.lang.Object.

Co: Covariant compareTo() method defined (CO_SELF_NO_OBJECT)

This class defines a covariant version of compareTo().  To correctly override the compareTo() method in the Comparable interface, the parameter of compareTo() must have type java.lang.Object.

DE: Method might drop exception (DE_MIGHT_DROP)

This method might drop an exception.  In general, exceptions should be handled or reported in some way, or they should be thrown out of the method.

DE: Method might ignore exception (DE_MIGHT_IGNORE)

This method might ignore an exception.  In general, exceptions should be handled or reported in some way, or they should be thrown out of the method.

DLS: Overwritten increment (DLS_OVERWRITTEN_INCREMENT)

The code performs an increment operation (e.g., i++) and then immediately overwrites it. For example, i = i++ immediately overwrites the incremented value with the original value.

DMI: Passes a constant value for a month outside of the expected range of 0..11 (DMI_BAD_MONTH)

This code passes a constant month value outside the expected range of 0..11 to a method.

DMI: hasNext method invokes next (DMI_CALLING_NEXT_FROM_HASNEXT)

The hasNext() method invokes the next() method. This is almost certainly wrong, since the hasNext() method is not supposed to change the state of the iterator, and the next method is supposed to change the state of the iterator.

DMI: Invocation of substring(0), which returns the original value (DMI_USELESS_SUBSTRING)

This code invokes substring(0) on a String, which returns the original value.

Dm: Method invokes System.exit(...) (DM_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.

Dm: Method invokes runFinalizersOnExit, one of the most dangerous methods in the Java libraries. (DM_RUN_FINALIZERS_ON_EXIT)

Never call System.runFinalizersOnExit or Runtime.runFinalizersOnExit for any reason: they are among the most dangerous methods in the Java libraries. -- Joshua Bloch

EC: Invocation of equals() on an array, which is equivalent to == (EC_BAD_ARRAY_COMPARE)

This method invokes the .equals(Object o) method on an array. Since arrays do not override the equals method of Object, calling equals on an array is the same as comparing their addresses. To compare the contents of the arrays, use java.util.Arrays.equals(Object[], Object[]).

EC: Call to equals() with null argument (EC_NULL_ARG)

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 unrelated class and interface (EC_UNRELATED_CLASS_AND_INTERFACE)

This method calls equals(Object) on two references, one of which is a class and the other an interface, where neither the class nor any of its non-abstract subclasses implement the interface. Therefore, the objects being compared are unlikely to be members of the same class at runtime (unless some application classes were not analyzed, or dynamic class loading can occur at runtime). According to the contract of equals(), objects of different classes should always compare as unequal; therefore, according to the contract defined by java.lang.Object.equals(Object), the result of this comparison will always be false at runtime.

EC: Call to equals() comparing different interface types (EC_UNRELATED_INTERFACES)

This method calls equals(Object) on two references of unrelated interface types, where neither is a subtype of the other, and there are no known non-abstract classes which implement both interfaces. Therefore, the objects being compared are unlikely to be members of the same class at runtime (unless some application classes were not analyzed, or dynamic class loading can occur at runtime). According to the contract of equals(), objects of different classes should always compare as unequal; therefore, according to the contract defined by java.lang.Object.equals(Object), the result of this comparison will always be false at runtime.

EC: Call to equals() comparing different types (EC_UNRELATED_TYPES)

This method calls equals(Object) on two references of different class types with no common subclasses. Therefore, the objects being compared are unlikely to be members of the same class at runtime (unless some application classes were not analyzed, or dynamic class loading can occur at runtime). According to the contract of equals(), objects of different classes should always compare as unequal; therefore, according to the contract defined by java.lang.Object.equals(Object), the result of this comparison will always be false at runtime.

ES: Comparison of String objects using == or != (ES_COMPARING_STRINGS_WITH_EQ)

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: Abstract class defines covariant equals() method (EQ_ABSTRACT_SELF)

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 (EQ_SELF_NO_OBJECT)

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 (EQ_SELF_USE_OBJECT)

This class defines a covariant version of the equals() method, but inherits 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).

FE: Test for floating point equality. (FE_FLOATING_POINT_EQUALITY)

This operation compares two floating point values for equality. Because floating point calculations may involve rounding, calculated float and double values may not be accurate. For values that must be precise, such as monetary values, consider using a fixed-precision type such as BigDecimal. For values that need not be precise, consider comparing for equality within some range, for example: if ( Math.abs(x - y) < .0000001 ). See the Java Language Specification, section 4.2.4.

FI: Explicit invocation of finalizer (FI_EXPLICIT_INVOCATION)

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 (FI_MISSING_SUPER_CALL)

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 (FI_NULLIFY_SUPER)

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() (HE_EQUALS_NO_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() (HE_EQUALS_USE_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() (HE_HASHCODE_NO_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() (HE_HASHCODE_USE_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() (HE_INHERITS_EQUALS_USE_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 (IC_INIT_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.

ICAST: Integer shift by an amount not in the range 0..31 (ICAST_BAD_SHIFT_AMOUNT)

The code performs an integer shift by a constant amount outside the range 0..31. The effect of this is to use the lower 5 bits of the integer value to decide how much to shift by. This probably isn't want was expected, and it at least confusing.

ICAST: Integer division result cast to double (ICAST_IDIV_CAST_TO_DOUBLE)

This code casts the result of an integer division operation to double. Doing division on integers loses precision. The fact that the result was cast to double suggests that this precision should have been retained. What was probably meant was to cast one or both of the operands to double before performing the division. Here is an example:

int x = 2;
int y = 5;
// Wrong: yields result 0.0
double value1 =  x / y;

// Right: yields result 0.4
double value2 =  x / (double) y;

ICAST: Integer value cast to double and then passed to Math.ceil (ICAST_INT_CAST_TO_DOUBLE_PASSED_TO_CEIL)

This code converts an integer value to a double precision floating point number and then passing the result to the Math.ceil() function, which rounds a double to the next higher integer value. This operation should always be a no-op, since the converting an integer to a double should give a number with no fractional part. It is likely that the operation that generated the value to be passed to Math.ceil was intended to be performed using double precision floating point arithmetic.

IJU: TestCase implements setUp but doesn't call super.setUp() (IJU_SETUP_NO_SUPER)

Class is a JUnit TestCase and implements the setUp method. The setUp method should call super.setUp(), but doesn't.

IJU: TestCase implements a suite method, but this method is not static and should be (IJU_SUITE_NOT_STATIC)

Class is a JUnit TestCase and implements the suite() method. The suite method should be declared as being static, but isn't.

IJU: TestCase implements tearDown but doesn't call super.tearDown() (IJU_TEARDOWN_NO_SUPER)

Class is a JUnit TestCase and implements the tearDown method. The tearDown method should call super.tearDown(), but doesn't.

IL: A container is added to itself. (IL_CONTAINER_ADDED_TO_ITSELF)

A container is added to itself. As a result, computing the hashCode of this set will throw a StackOverflowException.

IL: An apparent infinite recursive loop. (IL_INFINITE_RECURSIVE_LOOP)

This method unconditionally invokes itself. This would seem to indicate an infinite recursive loop that will result in a stack overflow.

IM: Integer multiply of result of integer remainder (IM_MULTIPLYING_RESULT_OF_IREM)

The code multiplies the result of an integer remaining by an integer constant. Be sure you don't have your operator precedence confused. For example i % 60 * 1000 is (i % 60) * 1000, not i % (60 * 1000).

IMSE: Dubious catching of IllegalMonitorStateException (IMSE_DONT_CATCH_IMSE)

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

IP: A parameter is dead upon entry to a method but overwritten (IP_PARAMETER_IS_DEAD_BUT_OVERWRITTEN)

The initial value of this parameter is ignored, and the parameter is overwritten here. This often indicates a mistaken belief that the write to the parameter will be conveyed back to the caller.

ISC: Needless instantiation of class that only supplies static methods (ISC_INSTANTIATE_STATIC_CLASS)

This class allocates an object that is based on a class that only supplies static methods. This object does not need to be created, just access the static methods directly using the class name as a qualifier.

It: Iterator next() method can't throw NoSuchElement exception (IT_NO_SUCH_ELEMENT)

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.

J2EE: Store of non serializable object into HttpSession (J2EE_STORE_OF_NON_SERIALIZABLE_OBJECT_INTO_SESSION)

This code seems to be storing a non-serializable object into an HttpSession. If this session is passivated or migrated, an error will result.

MF: Class defines field that obscures a superclass field (MF_CLASS_MASKS_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 (MF_METHOD_MASKS_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() (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() (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 (NP_ALWAYS_NULL)

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 (NP_ALWAYS_NULL_EXCEPTION)

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: equals() method does not check for null parameter (NP_DOES_NOT_HANDLE_NULL)

This implementation of equals(Object) violates the contract defined by java.lang.Object.equals() because it does not check for null being passed as the parameter. All equals() methods should return null if passed a null value.

NP: Immediate dereference of the result of readLine() (NP_IMMEDIATE_DEREFERENCE_OF_READLINE)

The result of invoking readLine() is immediately dereferenced. If there are no more lines of text to read, readLine() will return null and dereferencing that will generate a null pointer exception.

NP: Method call passes null to a parameter declared @NonNull (NP_NONNULL_PARAM_VIOLATION)

This method passes a null value as the parameter of a method which has declared that parameter to be @NonNull. (Note that the method with the @NonNull annotation may be in a subclass of the receiver object's class.)

NP: Method may return null, but is declared @NonNull (NP_NONNULL_RETURN_VIOLATION)

This method may return a null value, but the method (or a superclass method which it overrides) is declared to return @NonNull.

NP: Possible null pointer dereference in method (NP_NULL_ON_SOME_PATH)

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 (NP_NULL_ON_SOME_PATH_EXCEPTION)

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.

NP: Possible null pointer returned by method could be dereferenced (NP_NULL_ON_SOME_PATH_FROM_RETURN_VALUE)

A reference value dereferenced could be returned by a method that could have returned a null value. This may lead to a NullPointerException when the code is executed.

NP: Method call passes null for unconditionally dereferenced parameter (NP_NULL_PARAM_DEREF)

This method call passes a null value to a method which might dereference it unconditionally.

NP: Non-virtual method call passes null for unconditionally dereferenced parameter (NP_NULL_PARAM_DEREF_NONVIRTUAL)

A possibly-null value is passed to a method which unconditionally dereferences. This will almost certainly result in a null pointer exception.

NP: Read of unwritten field (NP_UNWRITTEN_FIELD)

The program is deferencing a field that does not seem to ever have a non-null value written to it. Deferencing this value will generate a null pointer exception.

NS: Questionable use of non-short-circuit logic (NS_NON_SHORT_CIRCUIT)

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()? (NM_BAD_EQUAL)

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: Class is not derived from an Exception, even though it is named as such (NM_CLASS_NOT_EXCEPTION)

This class is not derived from another exception, but ends with 'Exception'. This will be confusing to users of this class.

Nm: Confusing method names (NM_CONFUSING)

The referenced methods have names that differ only by capitalization.

Nm: Class defines hashcode(); should it be hashCode()? (NM_LCASE_HASHCODE)

This class defines a method called hashcode().  This method does not override the hashCode() method in java.lang.Object, which is probably what was intended.

Nm: Class defines tostring(); should it be toString()? (NM_LCASE_TOSTRING)

This class defines a method called tostring().  This method does not override the toString() method in java.lang.Object, which is probably what was intended.

Nm: Apparent method/constructor confusion (NM_METHOD_CONSTRUCTOR_CONFUSION)

This regular method has the same name as the class it is defined in. It is likely that this was intended to be a constructor. If it was intended to be a constructor, remove the declaration of a return value.

Nm: Very confusing method names (NM_VERY_CONFUSING)

The referenced methods have names that differ only by capitalization.

ODR: Method may fail to close database resource (ODR_OPEN_DATABASE_RESOURCE)

The method creates a database resource (such as a database connection or row set), does not assign it to any fields, pass it to other methods, or return it, and does not appear to close the object on all paths out of the method.  Failure to close database resources on all paths out of a method may result in poor performance, and could cause the application to have problems communicating with the database.

ODR: Method may fail to close database resource on exception (ODR_OPEN_DATABASE_RESOURCE_EXCEPTION_PATH)

The method creates a database resource (such as a database connection or row set), does not assign it to any fields, pass it to other methods, or return it, and does not appear to close the object on all exception paths out of the method.  Failure to close database resources on all paths out of a method may result in poor performance, and could cause the application to have problems communicating with the database.

OS: Method may fail to close stream (OS_OPEN_STREAM)

The method creates an IO stream object, does not assign it to any fields, pass it to other methods, or return it, and does not appear to close the stream on all paths out of the method.  This may result in a file descriptor leak.  It is generally a good idea to use a finally block to ensure that streams are closed.

OS: Method may fail to close stream on exception (OS_OPEN_STREAM_EXCEPTION_PATH)

The method creates an IO stream object, does not assign it to any fields, pass it to other methods, or return it, and does not appear to close it on all possible exception paths out of the method.  This may result in a file descriptor leak.  It is generally a good idea to use a finally block to ensure that streams are closed.

QF: Complicated, subtle or wrong increment in for-loop (QF_QUESTIONABLE_FOR_LOOP)

Are you sure this for loop is incrementing the correct variable? It appears that another variable is being initialized and checked by the for loop.

RC: Suspicious reference comparison (RC_REF_COMPARISON)

This method compares two reference values using the == or != operator, where the correct way to compare instances of this type is generally with the equals() method. Examples of classes which should generally not be compared by reference are java.lang.Integer, java.lang.Float, etc.

RCN: Redundant comparison of non-null value to null (RCN_REDUNDANT_COMPARISON_OF_NULL_AND_NONNULL_VALUE)

This method contains a reference known to be non-null with another reference known to be null.

RCN: Redundant comparison of two null values (RCN_REDUNDANT_COMPARISON_TWO_NULL_VALUES)

This method contains a redundant comparison of two references known to both be definitely null.

RCN: Redundant nullcheck of value known to be null (RCN_REDUNDANT_NULLCHECK_OF_NONNULL_VALUE)

This method contains a redundant check of a known non-null value against the constant null.

RCN: Redundant nullcheck of value known to be null (RCN_REDUNDANT_NULLCHECK_OF_NULL_VALUE)

This method contains a redundant check of a known null value against the constant null.

RCN: Nullcheck of value previously dereferenced (RCN_REDUNDANT_NULLCHECK_WOULD_HAVE_BEEN_A_NPE)

A value is checked here to see whether it is null, but this value can't be null because it was previously dereferences and if it were null a null pointer exception would have occurred. Essentially, this code and the previous dereference disagree as to whether this value is allowed to be null. Either the check is redundant or the previous dereference is erroneous.

RE: Invalid syntax for regular expression (RE_BAD_SYNTAX_FOR_REGULAR_EXPRESSION)

The code here uses a regular expression that is invalid according to the syntax for regular expressions. This statement throw a PatternSyntaxException when executed.

RR: Method ignores results of InputStream.read() (RR_NOT_CHECKED)

This method ignores the return value of one of the variants of java.io.InputStream.read() which can return multiple bytes.  If the return value is not checked, the caller will not be able to correctly handle the case where fewer bytes were read than the caller requested.  This is a particularly insidious kind of bug, because in many programs, reads from input streams usually do read the full amount of data requested, causing the program to fail only sporadically.

RR: Method ignores results of InputStream.skip() (SR_NOT_CHECKED)

This method ignores the return value of java.io.InputStream.skip() which can skip multiple bytes.  If the return value is not checked, the caller will not be able to correctly handle the case where fewer bytes were skipped than the caller requested.  This is a particularly insidious kind of bug, because in many programs, skips from input streams usually do skip the full amount of data requested, causing the program to fail only sporadically. With Buffered streams, however, skip() will only skip data in the buffer, and will routinely fail to skip the requested number of bytes.

RV: Random value from 0 to 1 is coerced to the integer 0 (RV_01_TO_INT)

A random value from 0 to 1 is being coerced to the integer value 0. You probably want to multiple the random value by something else before coercing it to an integer, or use use the Random.nextInt(n) method.

RV: Method checks to see if result of String.indexOf is positive (RV_CHECK_FOR_POSITIVE_INDEXOF)

The method invokes String.indexOf and checks to see if the result is positive or non-positive. It is much more typical to check to see if the result is negative or non-negative. It is positive only if the substring checked for occurs at some place other than at the beginning of the String.

RV: Method discards result of readLine after checking if it is nonnull (RV_DONT_JUST_NULL_CHECK_READLINE)

The value returned by readLine is discarded after checking to see if the return value is non-null. In almost all situations, if the result is non-null, you will want to use that non-null value. Calling readLine again will give you a different line.

RV: Method ignores return value (RV_RETURN_VALUE_IGNORED)

The return value of this method should be checked. One common cause of this warning is to invoke a method on an immutable object, thinking that it updates the object. For example, in the following code fragment,

String dateString = getHeaderField(name);
dateString.trim();

the programs seems to be thinking that the trim function will update the String referenced by dateString. But since Strings are immutable, the trim function returns a new String value, which is being ignored here. The code should be corrected to:

String dateString = getHeaderField(name);
dateString = dateString.trim();

SA: Self assignment of field (SA_FIELD_SELF_ASSIGNMENT)

This method contains a self assignment of a field; e.g.

  int x;
  public void foo() {
    x = x;
  }

Such assignments are useless, and may indicate a logic error or typo.

SI: Static initializer for class creates instance before all static final fields assigned (SI_INSTANCE_BEFORE_FINALS_ASSIGNED)

The class's static initializer creates an instance of the class before all of the static final fields are assigned.

SIO: Unnecessary type check done using instanceof operator (SIO_SUPERFLUOUS_INSTANCEOF)

Type check performed using the instanceof operator where it can be statically determined whether the object is of the type requested.

STI: Unneeded use of currentThread() call, to call interrupted() (STI_INTERRUPTED_ON_CURRENTTHREAD)

This method invokes the Thread.currentThread() call, just to call the interrupted() method. As interrupted() is a static method, is more simple and clear to use Thread.interrupted().

STI: Static Thread.interrupted() method is mistakenly attempted to be called on an arbitrary Thread object (STI_INTERRUPTED_ON_UNKNOWNTHREAD)

This method invokes the Thread.interrupted() method on a Thread object that appears to be a Thread object that is not the current thread. As the interrupted() method is static, the interrupted method will be called on a different object than the one the author intended.

SW: Certain swing methods should only be invoked from the Swing event thread (SW_SWING_METHODS_INVOKED_IN_SWING_THREAD)

(From JDC Tech Tip): The Swing methods show(), setVisible(), and pack() will create the associated peer for the frame. With the creation of the peer, the system creates the event dispatch thread. This makes things problematic because the event dispatch thread could be notifying listeners while pack and validate are still processing. This situation could result in two threads going through the Swing component-based GUI -- it's a serious flaw that could result in deadlocks or other related threading issues. A pack call causes components to be realized. As they are being realized (that is, not necessarily visible), they could trigger listener notification on the event dispatch thread.

Se: Non-transient non-serializable instance field in serializable class (SE_BAD_FIELD)

This Serializable class defines a non-primitive instance field which is neither transient, Serializable, or java.lang.Object, and does not appear to implement the Externalizable interface or the readObject() and writeObject() methods.  Objects of this class will not be deserialized correctly if a non-Serializable object is stored in this field.

Se: serialVersionUID isn't final (SE_NONFINAL_SERIALVERSIONID)

This class defines a serialVersionUID field that is not final.  The field should be made final if it is intended to specify the version UID for purposes of serialization.

Se: serialVersionUID isn't long (SE_NONLONG_SERIALVERSIONID)

This class defines a serialVersionUID field that is not long.  The field should be made long if it is intended to specify the version UID for purposes of serialization.

Se: serialVersionUID isn't static (SE_NONSTATIC_SERIALVERSIONID)

This class defines a serialVersionUID field that is not static.  The field should be made static if it is intended to specify the version UID for purposes of serialization.

Se: Class is Serializable but its superclass doesn't define a void constructor (SE_NO_SUITABLE_CONSTRUCTOR)

This class implements the Serializable interface and its superclass does not. When such an object is deserialized, the fields of the superclass need to be initialized by invoking the void constructor of the superclass. Since the superclass does not have one, serialization and deserialization will fail at runtime.

Se: Class is Externalizable but doesn't define a void constructor (SE_NO_SUITABLE_CONSTRUCTOR_FOR_EXTERNALIZATION)

This class implements the Externalizable interface, but does not define a void constructor. When Externalizable objects are deserialized, they first need to be constructed by invoking the void constructor. Since this class does not have one, serialization and deserialization will fail at runtime.

SnVI: Class is Serializable, but doesn't define serialVersionUID (SE_NO_SERIALVERSIONID)

This class implements the Serializable interface, but does not define a serialVersionUID field.  A change as simple as adding a reference to a .class object will add synthetic fields to the class, which will unfortunately change the implicit serialVersionUID (e.g., adding a reference to String.class will generate a static field class$java$lang$String). Also, different source code to bytecode compilers may use different naming conventions for synthetic variables generated for references to class objects or inner classes. To ensure interoperability of Serializable across versions, consider adding an explicit serialVersionUID.

UCF: Useless control flow in method (UCF_USELESS_CONTROL_FLOW)

This method contains a useless control flow statement.  Often, this is caused by inadvertently using an empty statement as the body of an if statement, e.g.:

    if (argv.length == 1);
        System.out.println("Hello, " + argv[0]);

UI: Usage of GetResource may be unsafe if class is extended (UI_INHERITANCE_UNSAFE_GETRESOURCE)

Calling this.getClass().getResource(...) could give results other than expected if this class is extended by a class in another package.

UR: Uninitialized read of field in constructor (UR_UNINIT_READ)

This constructor reads a field which has not yet been assigned a value.  This is often caused when the programmer mistakenly uses the field instead of one of the constructor's parameters.

UwF: Field only ever set to null (UWF_NULL_FIELD)

All writes to this field are of the constant value null, and thus all reads of the field will return null. Check for errors, or remove it if it is useless.

UwF: Unwritten field (UWF_UNWRITTEN_FIELD)

This field is never written.  All reads of it will return the default value. Check for errors (should it have been initialized?), or remove it if it is useless.

Dm: Method invokes dubious String.toUpperCase() or String.toLowerCase; use the Locale parameterized version instead (DM_CONVERT_CASE)

A String is being converted to upper or lowercase, using the platform's default encoding. This may result in improper conversions when used with international characters. Use the

String.toUpperCase( Locale l )
String.toLowerCase( Locale l )

versions instead.

EI: Method may expose internal representation by returning reference to mutable object (EI_EXPOSE_REP)

Returning a reference to a mutable object value stored in one of the object's fields exposes the internal representation of the object.  If instances are accessed by untrusted code, and unchecked changes to the mutable object would compromise security or other important properties, you will need to do something different. Returning a new copy of the object is better approach in many situations.

EI2: Method may expose internal representation by incorporating reference to mutable object (EI_EXPOSE_REP2)

This code stores a reference to an externally mutable object into the internal representation of the object.  If instances are accessed by untrusted code, and unchecked changes to the mutable object would compromise security or other important properties, you will need to do something different. Storing a copy of the object is better approach in many situations.

FI: Finalizer should be protected, not public (FI_PUBLIC_SHOULD_BE_PROTECTED)

A class's finalize() method should have protected access, not public.

MS: Method may expose internal static state by storing a mutable object into a static field (EI_EXPOSE_STATIC_REP2)

This code stores a reference to an externally mutable object into a static field. If unchecked changes to the mutable object would compromise security or other important properties, you will need to do something different. Storing a copy of the object is better approach in many situations.

MS: Field isn't final and can't be protected from malicious code (MS_CANNOT_BE_FINAL)

A mutable static field could be changed by malicious code or by accident from another package. Unfortunately, the way the field is used doesn't allow any easy fix to this problem.

MS: Public static method may expose internal representation by returning array (MS_EXPOSE_REP)

A public static method returns a reference to an array that is part of the static state of the class. Any code that calls this method can freely modify the underlying array. One fix is to return a copy of the array.

MS: Field should be both final and package protected (MS_FINAL_PKGPROTECT)

A mutable static field could be changed by malicious code or by accident from another package. The field could be made package protected and/or made final to avoid this vulnerability.

MS: Field is a mutable array (MS_MUTABLE_ARRAY)

A final static field references an array and can be accessed by malicious code or by accident from another package. This code can freely modify the contents of the array.

MS: Field is a mutable Hashtable (MS_MUTABLE_HASHTABLE)

A final static field references a Hashtable and can be accessed by malicious code or by accident from another package. This code can freely modify the contents of the Hashtable.

MS: Field should be moved out of an interface and made package protected (MS_OOI_PKGPROTECT)

A final static field that is defined in an interface references a mutable object such as an array or hashtable. This mutable object could be changed by malicious code or by accident from another package. To solve this, the field needs to be moved to a class and made package protected to avoid this vulnerability.

MS: Field should be package protected (MS_PKGPROTECT)

A mutable static field could be changed by malicious code or by accident. The field could be made package protected to avoid this vulnerability.

MS: Field isn't final but should be (MS_SHOULD_BE_FINAL)

A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.

DC: Possible double check of field (DC_DOUBLECHECK)

This method may contain an instance of double-checked locking.  This idiom is not correct according to the semantics of the Java memory model.  For more information, see the web page http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html.

Dm: Monitor wait() called on Condition (DM_MONITOR_WAIT_ON_CONDITION)

This method calls wait() on a java.util.concurrent.locks.Condition object.  Waiting for a Condition should be done using one of the await() methods defined by the Condition interface.

Dm: A thread was created using the default empty run method (DM_USELESS_THREAD)

This method creates a thread without specifying a run method either by deriving from the Thread class, or by passing a Runnable object. This thread, then, does nothing but waste time.

ESync: Empty synchronized block (ESync_EMPTY_SYNC)

The code contains an empty synchronized block:

synchronized() {}

Empty synchronized blocks are far more subtle and hard to use correctly than most people recognize, and empty synchronized blocks are almost never a better solution than less contrived solutions.

IS2: Inconsistent synchronization (IS2_INCONSISTENT_SYNC)

The fields of this class appear to be accessed inconsistently with respect to synchronization.  This bug report indicates that the bug pattern detector judged that

  1. The class contains a mix of locked and unlocked accesses,
  2. At least one locked access was performed by one of the class's own methods, and
  3. The number of unsynchronized field accesses (reads and writes) was no more than one third of all accesses, with writes being weighed twice as high as reads

A typical bug matching this bug pattern is forgetting to synchronize one of the methods in a class that is intended to be thread-safe.

You can select the nodes labeled "Unsynchronized access" to show the code locations where the detector believed that a field was accessed without synchronization.

Note that there are various sources of inaccuracy in this detector; for example, the detector cannot statically detect all situations in which a lock is held.  Also, even when the detector is accurate in distinguishing locked vs. unlocked accesses, the code in question may still be correct.

This description refers to the "IS2" version of the pattern detector, which has more accurate ways of detecting locked vs. unlocked accesses than the older "IS" detector.

JLM: Synchronization performed on java.util.concurrent Lock in method (JLM_JSR166_LOCK_MONITORENTER)

This method performs synchronization on an implementation of java.util.concurrent.locks.Lock. You should use the lock() and unlock() methods instead.

LI: Incorrect lazy initialization of static field (LI_LAZY_INIT_STATIC)

This method contains an unsynchronized lazy initialization of a non-volatile static field. Because the compiler or processor may reorder instructions, threads are not guaranteed to see a completely initialized object, if the method can be called by multiple threads. You can make the field volatile to correct the problem. For more information, see the Java Memory Model web site.

ML: Method synchronizes on an updated field (ML_SYNC_ON_UPDATED_FIELD)

This method synchronizes on an object references from a mutable field. This is unlikely to have useful semantics, since different threads may be synchronizing on different objects.

NN: Naked notify in method (NN_NAKED_NOTIFY)

A call to notify() or notifyAll() was made without any (apparent) accompanying modification to mutable object state.  In general, calling a notify method on a monitor is done because some condition another thread is waiting for has become true.  However, for the condition to be meaningful, it must involve a heap object that is visible to both threads.

This bug does not necessarily indicate an error, since the change to mutable object state may have taken place in a method which then called the method containing the notification.

No: Using notify() rather than notifyAll() in method (NO_NOTIFY_NOT_NOTIFYALL)

This method calls notify() rather than notifyAll().  Java monitors are often used for multiple conditions.  Calling notify() only wakes up one thread, meaning that the thread woken up might not be the one waiting for the condition that the caller just satisfied.

RS: Class's readObject() method is synchronized (RS_READOBJECT_SYNC)

This serializable class defines a readObject() which is synchronized.  By definition, an object created by deserialization is only reachable by one thread, and thus there is no need for readObject() to be synchronized.  If the readObject() method itself is causing the object to become visible to another thread, that is an example of very dubious coding style.

Ru: Invokes run on a thread (did you mean to start it instead?) (RU_INVOKE_RUN)

This method explicitly invokes run() on an object.  In general, classes implement the Runnable interface because they are going to have their run() method invoked in a new thread, in which case Thread.start() is the right method to call.

SC: Constructor invokes Thread.start() (SC_START_IN_CTOR)

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

SP: Method spins on field (SP_SPIN_ON_FIELD)

This method spins in a loop which reads a field.  The compiler may legally hoist the read out of the loop, turning the code into an infinite loop.  The class should be changed so it uses proper synchronization (including wait and notify calls).

SWL: Method calls Thread.sleep() with a lock held (SWL_SLEEP_WITH_LOCK_HELD)

This method calls Thread.sleep() with a lock held. This may result in very poor performance and scalability, or a deadlock, since other threads may be waiting to acquire the lock. It is a much better idea to call wait() on the lock, which releases the lock and allows other threads to run.

TLW: Wait with two locks held (TLW_TWO_LOCK_WAIT)

Waiting on a monitor while two locks are held may cause deadlock.   Performing a wait only releases the lock on the object being waited on, not any other locks.   This not necessarily a bug, but is worth examining closely.

UG: Unsynchronized get method, synchronized set method (UG_SYNC_SET_UNSYNC_GET)

This class contains similarly-named get and set methods where the set method is synchronized and the get method is not.  This may result in incorrect behavior at runtime, as callers of the get method will not necessarily see a consistent state for the object.  The get method should be made synchronized.

UL: Method does not release lock on all paths (UL_UNRELEASED_LOCK)

This method acquires a JSR-166 (java.util.concurrent) lock, but does not release it on all paths out of the method. In general, the correct idiom for using a JSR-166 lock is:

    Lock l = ...;
    l.lock();
    try {
        // do something
    } finally {
        l.unlock();
    }

UL: Method does not release lock on all exception paths (UL_UNRELEASED_LOCK_EXCEPTION_PATH)

This method acquires a JSR-166 (java.util.concurrent) lock, but does not release it on all exception paths out of the method. In general, the correct idiom for using a JSR-166 lock is:

    Lock l = ...;
    l.lock();
    try {
        // do something
    } finally {
        l.unlock();
    }

UW: Unconditional wait in method (UW_UNCOND_WAIT)

This method contains a call to java.lang.Object.wait() which is not guarded by conditional control flow.  If the condition that the method intends to wait for has already happened, the thread could wait indefinitely.

VO: A volatile reference to an array doesn't treat the array elements as volatile (VO_VOLATILE_REFERENCE_TO_ARRAY)

This declares a volatile reference to an array, which might not be what you want. With a volatile reference to an array, reads and writes of the reference to the array are treated as volatile, but the array elements are non-volatile. To get volatile array elements, you will need to use one of the atomic array classes in java.util.concurrent (provided in Java 5.0).

WS: Class's writeObject() method is synchronized but nothing else is (WS_WRITEOBJECT_SYNC)

This class has a writeObject() method which is synchronized; however, no other method of the class is synchronized.

Wa: Condition.await() not in loop in method (WA_AWAIT_NOT_IN_LOOP)

This method contains a call to java.util.concurrent.await() (or variants) which is not in a loop.  If the object is used for multiple conditions, the condition the caller intended to wait for might not be the one that actually occurred.

Wa: Wait not in loop in method (WA_NOT_IN_LOOP)

This method contains a call to java.lang.Object.wait() which is not in a loop.  If the monitor is used for multiple conditions, the condition the caller intended to wait for might not be the one that actually occurred.

Dm: Method invokes dubious Boolean constructor; use Boolean.valueOf(...) instead (DM_BOOLEAN_CTOR)

Creating new instances of java.lang.Boolean wastes memory, since Boolean objects are immutable and there are only two useful values of this type.  Use the Boolean.valueOf() method to create Boolean objects instead.

Dm: Method allocates a boxed primitive just to call toString (DM_BOXED_PRIMITIVE_TOSTRING)

A boxed primitive is allocated just to call toString(). It is more effective to just use the static form of toString which takes the primitive value. So,

Replace...With this...
new Integer(1).toString()Integer.toString(1)
new Long(1).toString()Long.toString(1)
new Float(1.0).toString()Float.toString(1.0)
new Double(1.0).toString()Double.toString(1.0)
new Byte(1).toString()Byte.toString(1)
new Short(1).toString()Short.toString(1)
new Boolean(true).toString()Boolean.toString(true)

Dm: Explicit garbage collection; extremely dubious except in benchmarking code (DM_GC)

Code explicitly invokes garbage collection. Except for specific use in benchmarking, this is very dubious.

In the past, situations where people have explicitly invoked the garbage collector in routines such as close or finalize methods has led to huge performance black holes. Garbage collection can be expensive. Any situation that forces hundreds or thousands of garbage collections will bring the machine to a crawl.

Dm: Method allocates an object, only to get the class object (DM_NEW_FOR_GETCLASS)

This method allocates an object just to call getClass() on it, in order to retrieve the Class object for it. It is simpler to just access the .class property of the class.

Dm: Use the nextInt method of Random rather than nextDouble to generate a random integer (DM_NEXTINT_VIA_NEXTDOUBLE)

If r is a java.util.Random, you can generate a random number from 0 to n-1 using r.nextInt(n) Rather than using (int)(r.nextDouble() * n).

Dm: Method invokes dubious new String(String) constructor; just use the argument (DM_STRING_CTOR)

Using the java.lang.String(String) constructor wastes memory because the object so constructed will be functionally indistinguishable from the String passed as a parameter.  Just use the argument String directly.

Dm: Method invokes dubious String.equals(""); use String.length() == 0 instead (DM_STRING_EMPTY_EQUALS)

An object is compared to the empty String object using the equals() method here. Checking that the String object's length is zero may be faster, and removes String constants from the class file.

Dm: Method invokes toString() method on a String; just use the String (DM_STRING_TOSTRING)

Calling String.toString() is just a redundant operation. Just use the String.

Dm: Method invokes dubious new String() constructor; just use "" (DM_STRING_VOID_CTOR)

Creating a new java.lang.String object using the no-argument constructor wastes memory because the object so created will be functionally indistinguishable from the empty string constant "".  Java guarantees that identical string constants will be represented by the same String object.  Therefore, you should just use the empty string constant directly.

FI: Empty finalizer should be deleted (FI_EMPTY)

Empty finalize() methods are useless, so they should be deleted.

FI: Finalizer does nothing but call superclass finalizer (FI_USELESS)

The only thing this finalize() method does is call the superclass's finalize() method, making it redundant.  Delete it.

ITA: Method uses toArray() with zero-length array argument (ITA_INEFFICIENT_TO_ARRAY)

This method uses the toArray() method of a collection derived class, and passes in a zero-length prototype array argument. It is more efficient to use

myCollection.toArray(new Foo[myCollection.size()])
If the array passed in is big enough to store all of the elements of the collection, then it is populated and returned directly. This avoids the need to create a second array (by reflection) to return as the result.

SBSC: Method concatenates strings using + in a loop (SBSC_USE_STRINGBUFFER_CONCATENATION)

The method seems to be building a String using concatenation in a loop. In each iteration, the String is converted to a StringBuffer/StringBuilder, appended to, and converted back to a String. This can lead to a cost quadratic in the number of iterations, as the growing string is recopied in each iteration.

Better performance can be obtained by using a StringBuffer (or StringBuilder in Java 1.5) explicitly.

For example:

  // This is bad
  String s = "";
  for (int i = 0; i < field.length; ++i) {
    s = s + field[i];
  }

  // This is better
  StringBuffer buf = new StringBuffer();
  for (int i = 0; i < field.length; ++i) {
    buf.append(field[i]);
  }
  String s = buf.toString();

SIC: Should be a static inner class (SIC_INNER_SHOULD_BE_STATIC)

This class is an inner class, but does not use its embedded reference to the object which created it.  This reference makes the instances of the class larger, and may keep the reference to the creator object alive longer than necessary.  If possible, the class should be be made static.

SIC: Could be refactored into a named static inner class (SIC_INNER_SHOULD_BE_STATIC_ANON)

This class is an inner class, but does not use its embedded reference to the object which created it.  This reference makes the instances of the class larger, and may keep the reference to the creator object alive longer than necessary.  If possible, the class should be made into a static inner class. Since anonymous inner classes cannot be marked as static, doing this will requiring refactoring the inner class so that it is a named inner class.

SIC: Could be refactored into a static inner class (SIC_INNER_SHOULD_BE_STATIC_NEEDS_THIS)

This class is an inner class, but does not use its embedded reference to the object which created it except during construction of the inner object.  This reference makes the instances of the class larger, and may keep the reference to the creator object alive longer than necessary.  If possible, the class should be made into a static inner class. Since the reference to the outer object is required during construction of the inner instance, the inner class will need to be refactored so as to pass a reference to the outer instance to the constructor for the inner class.

SS: Unread field: should this field be static? (SS_SHOULD_BE_STATIC)

This class contains an instance final field that is initialized to a compile-time static value. Consider making the field static.

UPM: Private method is never called (UPM_UNCALLED_PRIVATE_METHOD)

This private method is never called. Although it is possible that the method will be invoked through reflection, it is more likely that the method is never used, and should be removed.

UrF: Unread field (URF_UNREAD_FIELD)

This field is never read.  Consider removing it from the class.

UuF: Unused field (UUF_UNUSED_FIELD)

This field is never used.  Consider removing it from the class.

WMI: Inefficient use of keySet iterator instead of entrySet iterator (WMI_WRONG_MAP_ITERATOR)

This method accesses the value of a Map entry, using a key that was retrieved from a keySet iterator. It is more efficient to use an iterator on the entrySet of the map, to avoid the Map.get(key) lookup.

BC: Questionable cast to abstract collection (BC_BAD_CAST_TO_ABSTRACT_COLLECTION)

This code casts a Collection to an abstract collection (such as a Collection). Ensure that you are guaranteed that the object is of the type you are casting to. If all you need is to be able to iterate through a collection, you don't need to cast it to a Set or List.

BC: Questionable cast to concrete collection (BC_BAD_CAST_TO_CONCRETE_COLLECTION)

This code casts an abstract collection (such as a Collection, List, or Set) to a specific concrete implementation (such as an ArrayList or HashSet). This might not be correct, and it may make your code fragile, since it makes it harder to switch to other concrete implementations at a future point. Unless you have a particular reason to do so, just use the abstract collection class.

BC: Unchecked/unconfirmed cast (BC_UNCONFIRMED_CAST)

This cast is unchecked, and not all instances of the type casted from can be cast to the type it is being cast to. Ensure that your program logic ensures that this cast will not fail.

BC: instanceof will always return true (BC_VACUOUS_INSTANCEOF)

This instanceof test will always return true. Although this is safe, make sure it isn't an indication of some misunderstanding or some other logic error.

CD: Test for circular dependencies among classes. (CD_CIRCULAR_DEPENDENCY)

This class has a circular dependency with other classes. This makes building these classes difficult, as each is dependent on the other to build correctly. Consider using interfaces to break the hard dependency.

DB: Method uses the same code for two branches (DB_DUPLICATE_BRANCHES)

This method uses the same code to implement two branches of an if/else or switch statement.

DLS: Dead store to local variable (DLS_DEAD_LOCAL_STORE)

This instruction assigns a value to a local variable, but the value is not read by 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 local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.

ICAST: Unsigned right shift cast to short/byte (ICAST_QUESTIONABLE_UNSIGNED_RIGHT_SHIFT)

The code performs an unsigned right shift, whose result is then cast to a short or byte, which discards the upper bits of the result. Since the upper bits are discarded, there may be no difference between a signed and unsigned right shift (depending upon the size of the shift).

MTIA: Class extends Servlet class and uses instance variables. (MTIA_SUSPECT_SERVLET_INSTANCE_FIELD)

This class extends from a Servlet class, and uses a instance member variable. Since only one instance of a Servlet class is created by the j2ee framework, and used in a multithreaded way, this paradigm is highly discouraged and most likely problematic. Consider only using method local variables.

MTIA: Class extends Struts Action class and uses instance variables. (MTIA_SUSPECT_STRUTS_INSTANCE_FIELD)

This class extends from a Struts Action class, and uses a instance member variable. Since only one instance of a struts Action class is created by the Struts framework, and used in a multithreaded way, this paradigm is highly discouraged and most likely problematic. Consider only using method local variables.

NP: Read of field not initialized in constructor (NP_FIELD_NOT_INITIALIZED_IN_CONSTRUCTOR)

This is a read of a field is never initialized within any constructor, and is therefore could be null after the object is initialized. This might be a coding error, or else the class containing the field is written in a way that depends upon methods being called in some specific order (a little bit dodgy, but not necessarily wrong).

Nm: Class names should start with an upper case letter (NM_CLASS_NAMING_CONVENTION)

Class names should be nouns, in mixed case with the first letter of each internal word capitalized. Try to keep your class names simple and descriptive. Use whole words-avoid acronyms and abbreviations (unless the abbreviation is much more widely used than the long form, such as URL or HTML).

Nm: Field names should start with an lower case letter (NM_FIELD_NAMING_CONVENTION)

Names of fields that are not final should be in mixed case with a lowercase first letter and the first letters of subsequent words capitalized.

Nm: Method names should start with an lower case letter (NM_METHOD_NAMING_CONVENTION)

Methods should be verbs, in mixed case with the first letter lowercase, with the first letter of each internal word capitalized.

PS: Class exposes synchronization and semaphores in its public interface. (PS_PUBLIC_SEMAPHORES)

This class uses synchronization along with wait(), notify() or notifyAll() on itself (the this reference). Client classes that use this class, may, in addition, use an instance of this class as a synchronizing object. Because two classes are using the same object for synchronization, Multithread correctness is suspect. You should not synchronize nor call semaphore methods on a public reference. Consider using a internal private member variable to control synchronization.

PZLA: Consider returning a zero length array rather than null (PZLA_PREFER_ZERO_LENGTH_ARRAYS)

It is often a better design to return a length zero array rather than a null reference to indicate that there are no results (i.e., an empty list of results). This way, no explicit check for null is needed by clients of the method.

On the other hand, using null to indicate "there is no answer to this question", then it is probably appropriate. For example, File.listFiles() returns an empty list if given a directory containing no files, and returns null if the file is not a directory.

REC: java.lang.Exception is caught when Exception is not thrown (REC_CATCH_EXCEPTION)

This method uses a try-catch block that catches Exception objects, but Exception is not thrown within the try block, and RuntimeException is not explicitly caught. It is a common bug pattern to say try { ... } catch (Exception e) { something } as a shorthand for catching a number of types of exception each of whose catch blocks is identical, but this construct also accidentally catches RuntimeException as well, masking potential bugs.

RI: Class implements same interface as superclass. (RI_REDUNDANT_INTERFACES)

This class declares that it implements an interface that is also implemented by a superclass. This is redundant, once a superclass implements an interface, all subclasses by default also implement this interface. It may point out that the inheritance hierarchy has changed since this class was created, and consideration should be taken into account for the ownership of the interface's implementation.

SA: Self assignment of local variable (SA_LOCAL_SELF_ASSIGNMENT)

This method contains a self assignment of a local variable; e.g.

  public void foo() {
    int x = 3;
    x = x;
  }

Such assignments are useless, and may indicate a logic error or typo.

SF: Switch statement found where one case falls thru to the next case (SF_SWITCH_FALLTHROUGH)

This method contains a switch statement where one case branch will fall thru to the next case. Usually you need to end this case with a break or return.

ST: Write to static field from instance method (ST_WRITE_TO_STATIC_FROM_INSTANCE_METHOD)

This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.

TEST: Testing (TESTING)

This bug pattern is only generated by new, incompletely implemented bug detectors.

UM: Method calls static Math class method on a constant value (UM_UNNECESSARY_MATH)

This method uses a static method from java.lang.Math on a constant value. This method's result in this case, can be determined statically, and is faster and sometimes more accurate to just use the constant. Methods detected are:

absacosasinatanatan2cbrtceilcoscoshexpexpm1floorloglog10rintroundsinsinhsqrttantanhtoDegreestoRadians
MethodParameter
-any-
0.0 or 1.0
0.0 or 1.0
0.0 or 1.0
0.0
0.0 or 1.0
-any-
0.0
0.0
0.0 or 1.0
0.0
-any-
0.0 or 1.0
0.0 or 1.0
-any-
-any-
0.0
0.0
0.0 or 1.0
0.0
0.0
0.0 or 1.0
0.0

UwF: Field not initialized in constructor (UWF_FIELD_NOT_INITIALIZED_IN_CONSTRUCTOR)

This field is never initialized within any constructor, and is therefore could be null after the object is initialized. This is a either an error or a questionable design, since it means a null pointer exception will be generated if that field is dereferenced before being initialized.

XFB: Method directly allocates a specific implementation of xml interfaces (XFB_XML_FACTORY_BYPASS)

This method allocates a specific implementation of an xml interface. It is preferable to use the supplied factory classes to create these objects so that the implementation can be changed at runtime. See

  • javax.xml.parsers.DocumentBuilderFactory
  • javax.xml.parsers.SAXParserFactory
  • javax.xml.transform.TransformerFactory
  • org.w3c.dom.Document.createXXXX
for details.


Send comments to daveho@cs.umd.edu

SourceForge.net Logo