<html><head><title>FindBugs Bug Descriptions</title>
<link rel="stylesheet" type="text/css" href="findbugs.css"/>
<link rel="shortcut icon" href="favicon.ico" type="image/x-icon"/>
</head><body>
<table width="100%"><tr>
<td bgcolor="#b9b9fe" valign="top" align="left" width="20%">
<table width="100%" cellspacing="0" border="0">
<tr><td><a class="sidebar" href="index.html"><img src="umdFindbugs.png" alt="FindBugs"></a></td></tr>
<tr><td> </td></tr>
<tr><td><b>Docs and Info</b></td></tr>
<tr><td><font size="-1"><a class="sidebar" href="demo.html">Demo and data</a></font></td></tr>
<tr><td><font size="-1"><a class="sidebar" href="users.html">Users and supporters</a></font></td></tr>
<tr><td><font size="-1"><a class="sidebar" href="http://findbugs.blogspot.com/">FindBugs blog</a></font></td></tr>
<tr><td><font size="-1"><a class="sidebar" href="factSheet.html">Fact sheet</a></font></td></tr>
<tr><td><font size="-1"><a class="sidebar" href="manual/index.html">Manual (en)</a></font></td></tr>
<tr><td><font size="-1"><a class="sidebar" href="http://www.simeji.com/findbugs/doc/manual_ja/index.html">Manual (ja)</a></font></td></tr>
<tr><td><font size="-1"><a class="sidebar" href="FAQ.html">FAQ</a></font></td></tr>
<tr><td><font size="-1"><a class="sidebar" href="bugDescriptions.html">Bug descriptions</a></font></td></tr>
<tr><td><font size="-1"><a class="sidebar" href="mailingLists.html">Mailing lists</a></font></td></tr>
<tr><td><font size="-1"><a class="sidebar" href="publications.html">Documents and Publications</a></font></td></tr>
<tr><td><font size="-1"><a class="sidebar" href="links.html">Links</a></font></td></tr>
<tr><td> </td></tr>
<tr><td><a class="sidebar" href="downloads.html"><b>Downloads</b></a></td></tr>
<tr><td> </td></tr>
<tr><td><a class="sidebar" href="http://www.cafeshops.com/findbugs"><b>FindBugs Swag</b></a></td></tr>
<tr><td> </td></tr>
<tr><td><b>Development</b></td></tr>
<tr><td><font size="-1"><a class="sidebar" href="reportingBugs.html">Reporting bugs</a></font></td></tr>
<tr><td><font size="-1"><a class="sidebar" href="contributing.html">Contributing</a></font></td></tr>
<tr><td><font size="-1"><a class="sidebar" href="team.html">Dev team</a></font></td></tr>
<tr><td><font size="-1"><a class="sidebar" href="api/index.html">API</a> <a class="sidebar" href="api/overview-summary.html">[no frames]</a></font></td></tr>
<tr><td><font size="-1"><a class="sidebar" href="Changes.html">Change log</a></font></td></tr>
<tr><td><font size="-1"><a class="sidebar" href="http://sourceforge.net/projects/findbugs">SF project page</a></font></td></tr>
<tr><td><font size="-1"><a class="sidebar" href="http://findbugs.cvs.sourceforge.net/findbugs">Browse source</a></font></td></tr>
</table>
</td>
<td align="left" valign="top">
<h1>FindBugs Bug Descriptions</h1>
<p>This document lists the standard bug patterns reported by
<a href="http://findbugs.sourceforge.net">FindBugs</a> version 1.2.1.</p>
<h2>Summary</h2>
<table width="100%">
<tr bgcolor="#b9b9fe"><th>Description</th><th>Category</th></tr>
<tr bgcolor="#eeeeee"><td><a href="#AM_CREATES_EMPTY_JAR_FILE_ENTRY">AM: Creates an empty jar file entry</a></td><td>Bad practice</td></tr>
<tr bgcolor="#ffffff"><td><a href="#AM_CREATES_EMPTY_ZIP_FILE_ENTRY">AM: Creates an empty zip file entry</a></td><td>Bad practice</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#BC_EQUALS_METHOD_SHOULD_WORK_FOR_ALL_OBJECTS">BC: Equals method should not assume anything about the type of its argument</a></td><td>Bad practice</td></tr>
<tr bgcolor="#ffffff"><td><a href="#DMI_RANDOM_USED_ONLY_ONCE">BC: Random object created and used only once</a></td><td>Bad practice</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#CN_IDIOM">CN: Class implements Cloneable but does not define or use clone method</a></td><td>Bad practice</td></tr>
<tr bgcolor="#ffffff"><td><a href="#CN_IDIOM_NO_SUPER_CALL">CN: clone method does not call super.clone()</a></td><td>Bad practice</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#CO_ABSTRACT_SELF">Co: Abstract class defines covariant compareTo() method</a></td><td>Bad practice</td></tr>
<tr bgcolor="#ffffff"><td><a href="#CO_SELF_NO_OBJECT">Co: Covariant compareTo() method defined</a></td><td>Bad practice</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#DE_MIGHT_DROP">DE: Method might drop exception</a></td><td>Bad practice</td></tr>
<tr bgcolor="#ffffff"><td><a href="#DE_MIGHT_IGNORE">DE: Method might ignore exception</a></td><td>Bad practice</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#DP_CREATE_CLASSLOADER_INSIDE_DO_PRIVILEGED">DP: Classloaders should only be created inside doPrivileged block</a></td><td>Bad practice</td></tr>
<tr bgcolor="#ffffff"><td><a href="#DP_DO_INSIDE_DO_PRIVILEGED">DP: Method invoked that should be only be invoked inside a doPrivileged block</a></td><td>Bad practice</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#DM_EXIT">Dm: Method invokes System.exit(...)</a></td><td>Bad practice</td></tr>
<tr bgcolor="#ffffff"><td><a href="#DM_RUN_FINALIZERS_ON_EXIT">Dm: Method invokes dangerous method runFinalizersOnExit </a></td><td>Bad practice</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#ES_COMPARING_PARAMETER_STRING_WITH_EQ">ES: Comparison of String parameter using == or !=</a></td><td>Bad practice</td></tr>
<tr bgcolor="#ffffff"><td><a href="#ES_COMPARING_STRINGS_WITH_EQ">ES: Comparison of String objects using == or !=</a></td><td>Bad practice</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#EQ_ABSTRACT_SELF">Eq: Abstract class defines covariant equals() method</a></td><td>Bad practice</td></tr>
<tr bgcolor="#ffffff"><td><a href="#EQ_COMPARETO_USE_OBJECT_EQUALS">Eq: Class defines compareTo(...) and uses Object.equals()</a></td><td>Bad practice</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#EQ_SELF_NO_OBJECT">Eq: Covariant equals() method defined</a></td><td>Bad practice</td></tr>
<tr bgcolor="#ffffff"><td><a href="#EQ_SELF_USE_OBJECT">Eq: Covariant equals() method defined, Object.equals(Object) inherited</a></td><td>Bad practice</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#FI_EMPTY">FI: Empty finalizer should be deleted</a></td><td>Bad practice</td></tr>
<tr bgcolor="#ffffff"><td><a href="#FI_EXPLICIT_INVOCATION">FI: Explicit invocation of finalizer</a></td><td>Bad practice</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#FI_FINALIZER_NULLS_FIELDS">FI: Finalizer nulls fields</a></td><td>Bad practice</td></tr>
<tr bgcolor="#ffffff"><td><a href="#FI_FINALIZER_ONLY_NULLS_FIELDS">FI: Finalizer only nulls fields</a></td><td>Bad practice</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#FI_MISSING_SUPER_CALL">FI: Finalizer does not call superclass finalizer</a></td><td>Bad practice</td></tr>
<tr bgcolor="#ffffff"><td><a href="#FI_NULLIFY_SUPER">FI: Finalizer nullifies superclass finalizer</a></td><td>Bad practice</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#FI_USELESS">FI: Finalizer does nothing but call superclass finalizer</a></td><td>Bad practice</td></tr>
<tr bgcolor="#ffffff"><td><a href="#HE_EQUALS_NO_HASHCODE">HE: Class defines equals() but not hashCode()</a></td><td>Bad practice</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#HE_EQUALS_USE_HASHCODE">HE: Class defines equals() and uses Object.hashCode()</a></td><td>Bad practice</td></tr>
<tr bgcolor="#ffffff"><td><a href="#HE_HASHCODE_NO_EQUALS">HE: Class defines hashCode() but not equals()</a></td><td>Bad practice</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#HE_HASHCODE_USE_OBJECT_EQUALS">HE: Class defines hashCode() and uses Object.equals()</a></td><td>Bad practice</td></tr>
<tr bgcolor="#ffffff"><td><a href="#HE_INHERITS_EQUALS_USE_HASHCODE">HE: Class inherits equals() and uses Object.hashCode()</a></td><td>Bad practice</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#IC_SUPERCLASS_USES_SUBCLASS_DURING_INITIALIZATION">IC: Superclass uses subclass during initialization</a></td><td>Bad practice</td></tr>
<tr bgcolor="#ffffff"><td><a href="#IMSE_DONT_CATCH_IMSE">IMSE: Dubious catching of IllegalMonitorStateException</a></td><td>Bad practice</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#ISC_INSTANTIATE_STATIC_CLASS">ISC: Needless instantiation of class that only supplies static methods</a></td><td>Bad practice</td></tr>
<tr bgcolor="#ffffff"><td><a href="#IT_NO_SUCH_ELEMENT">It: Iterator next() method can't throw NoSuchElement exception</a></td><td>Bad practice</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#J2EE_STORE_OF_NON_SERIALIZABLE_OBJECT_INTO_SESSION">J2EE: Store of non serializable object into HttpSession</a></td><td>Bad practice</td></tr>
<tr bgcolor="#ffffff"><td><a href="#NP_CLONE_COULD_RETURN_NULL">NP: Clone method may return null</a></td><td>Bad practice</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#NP_EQUALS_SHOULD_HANDLE_NULL_ARGUMENT">NP: equals() method does not check for null argument</a></td><td>Bad practice</td></tr>
<tr bgcolor="#ffffff"><td><a href="#NP_TOSTRING_COULD_RETURN_NULL">NP: toString method may return null</a></td><td>Bad practice</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#NS_NON_SHORT_CIRCUIT">NS: Questionable use of non-short-circuit logic</a></td><td>Bad practice</td></tr>
<tr bgcolor="#ffffff"><td><a href="#NM_CLASS_NAMING_CONVENTION">Nm: Class names should start with an upper case letter</a></td><td>Bad practice</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#NM_CLASS_NOT_EXCEPTION">Nm: Class is not derived from an Exception, even though it is named as such</a></td><td>Bad practice</td></tr>
<tr bgcolor="#ffffff"><td><a href="#NM_CONFUSING">Nm: Confusing method names</a></td><td>Bad practice</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#NM_FIELD_NAMING_CONVENTION">Nm: Field names should start with an lower case letter</a></td><td>Bad practice</td></tr>
<tr bgcolor="#ffffff"><td><a href="#NM_FUTURE_KEYWORD_USED_AS_IDENTIFIER">Nm: Use of identifier that is a keyword in later versions of Java</a></td><td>Bad practice</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#NM_FUTURE_KEYWORD_USED_AS_MEMBER_IDENTIFIER">Nm: Use of identifier that is a keyword in later versions of Java</a></td><td>Bad practice</td></tr>
<tr bgcolor="#ffffff"><td><a href="#NM_METHOD_NAMING_CONVENTION">Nm: Method names should start with an lower case letter</a></td><td>Bad practice</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#NM_VERY_CONFUSING_INTENTIONAL">Nm: Very confusing method names (but intentional)</a></td><td>Bad practice</td></tr>
<tr bgcolor="#ffffff"><td><a href="#ODR_OPEN_DATABASE_RESOURCE">ODR: Method may fail to close database resource</a></td><td>Bad practice</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#ODR_OPEN_DATABASE_RESOURCE_EXCEPTION_PATH">ODR: Method may fail to close database resource on exception</a></td><td>Bad practice</td></tr>
<tr bgcolor="#ffffff"><td><a href="#OS_OPEN_STREAM">OS: Method may fail to close stream</a></td><td>Bad practice</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#OS_OPEN_STREAM_EXCEPTION_PATH">OS: Method may fail to close stream on exception</a></td><td>Bad practice</td></tr>
<tr bgcolor="#ffffff"><td><a href="#RR_NOT_CHECKED">RR: Method ignores results of InputStream.read()</a></td><td>Bad practice</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#SR_NOT_CHECKED">RR: Method ignores results of InputStream.skip()</a></td><td>Bad practice</td></tr>
<tr bgcolor="#ffffff"><td><a href="#SI_INSTANCE_BEFORE_FINALS_ASSIGNED">SI: Static initializer creates instance before all static final fields assigned</a></td><td>Bad practice</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#SQL_NONCONSTANT_STRING_PASSED_TO_EXECUTE">SQL: Nonconstant string passed to execute method on an SQL statement</a></td><td>Bad practice</td></tr>
<tr bgcolor="#ffffff"><td><a href="#SQL_PREPARED_STATEMENT_GENERATED_FROM_NONCONSTANT_STRING">SQL: A prepared statement is generated from a nonconstant String</a></td><td>Bad practice</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#SW_SWING_METHODS_INVOKED_IN_SWING_THREAD">SW: Certain swing methods needs to be invoked in Swing thread</a></td><td>Bad practice</td></tr>
<tr bgcolor="#ffffff"><td><a href="#SE_BAD_FIELD">Se: Non-transient non-serializable instance field in serializable class</a></td><td>Bad practice</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#SE_BAD_FIELD_INNER_CLASS">Se: Non-serializable class has a serializable inner class</a></td><td>Bad practice</td></tr>
<tr bgcolor="#ffffff"><td><a href="#SE_BAD_FIELD_STORE">Se: Non-serializable value stored into instance field of a serializable class</a></td><td>Bad practice</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#SE_COMPARATOR_SHOULD_BE_SERIALIZABLE">Se: Comparator doesn't implement Serializable</a></td><td>Bad practice</td></tr>
<tr bgcolor="#ffffff"><td><a href="#SE_INNER_CLASS">Se: Serializable inner class</a></td><td>Bad practice</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#SE_METHOD_MUST_BE_PRIVATE">Se: Method must be private in order for serialization to work</a></td><td>Bad practice</td></tr>
<tr bgcolor="#ffffff"><td><a href="#SE_NONFINAL_SERIALVERSIONID">Se: serialVersionUID isn't final</a></td><td>Bad practice</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#SE_NONLONG_SERIALVERSIONID">Se: serialVersionUID isn't long</a></td><td>Bad practice</td></tr>
<tr bgcolor="#ffffff"><td><a href="#SE_NONSTATIC_SERIALVERSIONID">Se: serialVersionUID isn't static</a></td><td>Bad practice</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#SE_NO_SUITABLE_CONSTRUCTOR">Se: Class is Serializable but its superclass doesn't define a void constructor</a></td><td>Bad practice</td></tr>
<tr bgcolor="#ffffff"><td><a href="#SE_NO_SUITABLE_CONSTRUCTOR_FOR_EXTERNALIZATION">Se: Class is Externalizable but doesn't define a void constructor</a></td><td>Bad practice</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#SE_READ_RESOLVE_MUST_RETURN_OBJECT">Se: The readResolve method must be declared with a return type
of Object. </a></td><td>Bad practice</td></tr>
<tr bgcolor="#ffffff"><td><a href="#SE_TRANSIENT_FIELD_NOT_RESTORED">Se: Transient field that isn't set by deserialization. </a></td><td>Bad practice</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#SE_NO_SERIALVERSIONID">SnVI: Class is Serializable, but doesn't define serialVersionUID</a></td><td>Bad practice</td></tr>
<tr bgcolor="#ffffff"><td><a href="#UI_INHERITANCE_UNSAFE_GETRESOURCE">UI: Usage of GetResource may be unsafe if class is extended</a></td><td>Bad practice</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#BC_IMPOSSIBLE_CAST">BC: Impossible cast</a></td><td>Correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#BC_IMPOSSIBLE_INSTANCEOF">BC: instanceof will always return false</a></td><td>Correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#BIT_AND">BIT: Incompatible bit masks</a></td><td>Correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#BIT_AND_ZZ">BIT: Check to see if ((...) & 0) == 0</a></td><td>Correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#BIT_IOR">BIT: Incompatible bit masks</a></td><td>Correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#BIT_IOR_OF_SIGNED_BYTE">BIT: Bitwise OR of signed byte value</a></td><td>Correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#BOA_BADLY_OVERRIDDEN_ADAPTER">BOA: Class overrides a method implemented in super class Adapter wrongly</a></td><td>Correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#BX_UNBOXED_AND_COERCED_FOR_TERNARY_OPERATOR">Bx: Primitive value is unboxed and coerced for ternary operator</a></td><td>Correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#DLS_OVERWRITTEN_INCREMENT">DLS: Overwritten increment</a></td><td>Correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#DMI_BAD_MONTH">DMI: Bad constant value for month</a></td><td>Correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#DMI_CALLING_NEXT_FROM_HASNEXT">DMI: hasNext method invokes next</a></td><td>Correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#DMI_INVOKING_TOSTRING_ON_ARRAY">DMI: Invocation of toString on an array</a></td><td>Correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#DMI_LONG_BITS_TO_DOUBLE_INVOKED_ON_INT">DMI: Double.longBitsToDouble invoked on an int</a></td><td>Correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#DMI_ANNOTATION_IS_NOT_VISIBLE_TO_REFLECTION">Dm: Can't use reflection to check for presence of annotation with default retention</a></td><td>Correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#EC_ARRAY_AND_NONARRAY">EC: equals() used to compare array and nonarray</a></td><td>Correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#EC_BAD_ARRAY_COMPARE">EC: Invocation of equals() on an array, which is equivalent to ==</a></td><td>Correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#EC_NULL_ARG">EC: Call to equals() with null argument</a></td><td>Correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#EC_UNRELATED_CLASS_AND_INTERFACE">EC: Call to equals() comparing unrelated class and interface</a></td><td>Correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#EC_UNRELATED_INTERFACES">EC: Call to equals() comparing different interface types</a></td><td>Correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#EC_UNRELATED_TYPES">EC: Call to equals() comparing different types</a></td><td>Correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#EQ_DONT_DEFINE_EQUALS_FOR_ENUM">Eq: Covariant equals() method defined for enum</a></td><td>Correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#FE_TEST_IF_EQUAL_TO_NOT_A_NUMBER">FE: Doomed test for equality to NaN</a></td><td>Correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#GC_UNRELATED_TYPES">GC: No relationship between generic parameter and method argument</a></td><td>Correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#HE_USE_OF_UNHASHABLE_CLASS">HE: Use of class without a hashCode() method in a hashed data structure</a></td><td>Correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#ICAST_BAD_SHIFT_AMOUNT">ICAST: Integer shift by an amount not in the range 0..31</a></td><td>Correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#ICAST_INT_CAST_TO_DOUBLE_PASSED_TO_CEIL">ICAST: int value cast to double and then passed to Math.ceil</a></td><td>Correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#ICAST_INT_CAST_TO_FLOAT_PASSED_TO_ROUND">ICAST: int value cast to float and then passed to Math.round</a></td><td>Correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#IJU_ASSERT_METHOD_INVOKED_FROM_RUN_METHOD">IJU: JUnit assertion in run method will not be noticed by JUnit</a></td><td>Correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#IJU_BAD_SUITE_METHOD">IJU: TestCase declares a bad suite method </a></td><td>Correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#IJU_NO_TESTS">IJU: TestCase has no tests</a></td><td>Correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#IJU_SETUP_NO_SUPER">IJU: TestCase implements setUp but doesn't call super.setUp()</a></td><td>Correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#IJU_SUITE_NOT_STATIC">IJU: TestCase implements a non-static suite method </a></td><td>Correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#IJU_TEARDOWN_NO_SUPER">IJU: TestCase implements tearDown but doesn't call super.tearDown()</a></td><td>Correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#IL_CONTAINER_ADDED_TO_ITSELF">IL: A container is added to itself</a></td><td>Correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#IL_INFINITE_LOOP">IL: An apparent infinite loop</a></td><td>Correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#IL_INFINITE_RECURSIVE_LOOP">IL: An apparent infinite recursive loop</a></td><td>Correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#IM_MULTIPLYING_RESULT_OF_IREM">IM: Integer multiply of result of integer remainder</a></td><td>Correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#INT_BAD_COMPARISON_WITH_NONNEGATIVE_VALUE">INT: Bad comparison of nonnegative value with negative constant</a></td><td>Correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#INT_BAD_COMPARISON_WITH_SIGNED_BYTE">INT: Bad comparison of signed byte</a></td><td>Correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#INT_BAD_REM_BY_1">INT: Integer remainder modulo 1</a></td><td>Correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#IP_PARAMETER_IS_DEAD_BUT_OVERWRITTEN">IP: A parameter is dead upon entry to a method but overwritten</a></td><td>Correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#JCIP_FIELD_ISNT_FINAL_IN_IMMUTABLE_CLASS">JCIP: Fields of immutable classes should be final</a></td><td>Correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#MF_CLASS_MASKS_FIELD">MF: Class defines field that masks a superclass field</a></td><td>Correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#MF_METHOD_MASKS_FIELD">MF: Method defines a variable that obscures a field</a></td><td>Correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#NP_ALWAYS_NULL">NP: Null pointer dereference</a></td><td>Correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#NP_ALWAYS_NULL_EXCEPTION">NP: Null pointer dereference in method on exception path</a></td><td>Correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#NP_ARGUMENT_MIGHT_BE_NULL">NP: Method does not check for null argument</a></td><td>Correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#NP_GUARANTEED_DEREF">NP: Null value is guaranteed to be dereferenced</a></td><td>Correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#NP_GUARANTEED_DEREF_ON_EXCEPTION_PATH">NP: Value is null and guaranteed to be dereferenced on exception path</a></td><td>Correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#NP_NONNULL_PARAM_VIOLATION">NP: Method call passes null to a nonnull parameter </a></td><td>Correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#NP_NONNULL_RETURN_VIOLATION">NP: Method may return null, but is declared @NonNull</a></td><td>Correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#NP_NULL_INSTANCEOF">NP: A known null value is checked to see if it is an instance of a type</a></td><td>Correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#NP_NULL_ON_SOME_PATH">NP: Possible null pointer dereference</a></td><td>Correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#NP_NULL_ON_SOME_PATH_EXCEPTION">NP: Possible null pointer dereference in method on exception path</a></td><td>Correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#NP_NULL_PARAM_DEREF">NP: Method call passes null for unconditionally dereferenced parameter</a></td><td>Correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#NP_NULL_PARAM_DEREF_ALL_TARGETS_DANGEROUS">NP: Method call passes null for unconditionally dereferenced parameter</a></td><td>Correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#NP_NULL_PARAM_DEREF_NONVIRTUAL">NP: Non-virtual method call passes null for unconditionally dereferenced parameter</a></td><td>Correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#NP_STORE_INTO_NONNULL_FIELD">NP: Store of null value into field annotated NonNull</a></td><td>Correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#NP_UNWRITTEN_FIELD">NP: Read of unwritten field</a></td><td>Correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#NS_DANGEROUS_NON_SHORT_CIRCUIT">NS: Potentially dangerous use of non-short-circuit logic</a></td><td>Correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#NM_BAD_EQUAL">Nm: Class defines equal(); should it be equals()?</a></td><td>Correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#NM_LCASE_HASHCODE">Nm: Class defines hashcode(); should it be hashCode()?</a></td><td>Correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#NM_LCASE_TOSTRING">Nm: Class defines tostring(); should it be toString()?</a></td><td>Correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#NM_METHOD_CONSTRUCTOR_CONFUSION">Nm: Apparent method/constructor confusion</a></td><td>Correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#NM_VERY_CONFUSING">Nm: Very confusing method names</a></td><td>Correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#QBA_QUESTIONABLE_BOOLEAN_ASSIGNMENT">QBA: Method assigns boolean literal in boolean expression</a></td><td>Correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#RC_REF_COMPARISON">RC: Suspicious reference comparison</a></td><td>Correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#RCN_REDUNDANT_NULLCHECK_WOULD_HAVE_BEEN_A_NPE">RCN: Nullcheck of value previously dereferenced</a></td><td>Correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#RE_BAD_SYNTAX_FOR_REGULAR_EXPRESSION">RE: Invalid syntax for regular expression</a></td><td>Correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#RE_CANT_USE_FILE_SEPARATOR_AS_REGULAR_EXPRESSION">RE: File.separator used for regular expression</a></td><td>Correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#RE_POSSIBLE_UNINTENDED_PATTERN">RE: "." used for regular expression</a></td><td>Correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#RV_01_TO_INT">RV: Random value from 0 to 1 is coerced to the integer 0</a></td><td>Correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#RV_ABSOLUTE_VALUE_OF_HASHCODE">RV: Bad attempt to compute absolute value of signed 32-bit hashcode </a></td><td>Correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#RV_ABSOLUTE_VALUE_OF_RANDOM_INT">RV: Bad attempt to compute absolute value of signed 32-bit random integer</a></td><td>Correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#RV_DONT_JUST_NULL_CHECK_READLINE">RV: Method discards result of readLine after checking if it is nonnull</a></td><td>Correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#RV_RETURN_VALUE_IGNORED">RV: Method ignores return value</a></td><td>Correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#SA_FIELD_DOUBLE_ASSIGNMENT">SA: Double assignment of field</a></td><td>Correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#SA_FIELD_SELF_ASSIGNMENT">SA: Self assignment of field</a></td><td>Correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#SA_FIELD_SELF_COMPARISON">SA: Self comparison of field with itself</a></td><td>Correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#SA_FIELD_SELF_COMPUTATION">SA: Nonsensical self computation involving a field (e.g., x & x)</a></td><td>Correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#SA_LOCAL_DOUBLE_ASSIGNMENT">SA: Double assignment of local variable </a></td><td>Correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#SA_LOCAL_SELF_COMPARISON">SA: Self comparison of value with itself</a></td><td>Correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#SA_LOCAL_SELF_COMPUTATION">SA: Nonsensical self computation involving a variable (e.g., x & x)</a></td><td>Correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#SF_DEAD_STORE_DUE_TO_SWITCH_FALLTHROUGH">SF: Dead store due to switch statement fall through</a></td><td>Correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#SIO_SUPERFLUOUS_INSTANCEOF">SIO: Unnecessary type check done using instanceof operator</a></td><td>Correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#SQL_BAD_PREPARED_STATEMENT_ACCESS">SQL: Method attempts to access a prepared statement parameter with index 0</a></td><td>Correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#SQL_BAD_RESULTSET_ACCESS">SQL: Method attempts to access a result set field with index 0</a></td><td>Correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#STI_INTERRUPTED_ON_CURRENTTHREAD">STI: Unneeded use of currentThread() call, to call interrupted() </a></td><td>Correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#STI_INTERRUPTED_ON_UNKNOWNTHREAD">STI: Static Thread.interrupted() method invoked on thread instance</a></td><td>Correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#UCF_USELESS_CONTROL_FLOW_NEXT_LINE">UCF: Useless control flow to next line</a></td><td>Correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#UMAC_UNCALLABLE_METHOD_OF_ANONYMOUS_CLASS">UMAC: Uncallable method defined in anonymous class</a></td><td>Correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#UR_UNINIT_READ">UR: Uninitialized read of field in constructor</a></td><td>Correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#UWF_NULL_FIELD">UwF: Field only ever set to null</a></td><td>Correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#UWF_UNWRITTEN_FIELD">UwF: Unwritten field</a></td><td>Correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#VA_PRIMITIVE_ARRAY_PASSED_TO_OBJECT_VARARG">VA: Primitive array passed to function expecting a variable number of object arguments</a></td><td>Correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#DM_CONVERT_CASE">Dm: Consider using Locale parameterized version of invoked method</a></td><td>Internationalization</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#EI_EXPOSE_REP">EI: May expose internal representation by returning reference to mutable object</a></td><td>Malicious code vulnerability</td></tr>
<tr bgcolor="#ffffff"><td><a href="#EI_EXPOSE_REP2">EI2: May expose internal representation by incorporating reference to mutable object</a></td><td>Malicious code vulnerability</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#FI_PUBLIC_SHOULD_BE_PROTECTED">FI: Finalizer should be protected, not public</a></td><td>Malicious code vulnerability</td></tr>
<tr bgcolor="#ffffff"><td><a href="#EI_EXPOSE_STATIC_REP2">MS: May expose internal static state by storing a mutable object into a static field</a></td><td>Malicious code vulnerability</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#MS_CANNOT_BE_FINAL">MS: Field isn't final and can't be protected from malicious code</a></td><td>Malicious code vulnerability</td></tr>
<tr bgcolor="#ffffff"><td><a href="#MS_EXPOSE_REP">MS: Public static method may expose internal representation by returning array</a></td><td>Malicious code vulnerability</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#MS_FINAL_PKGPROTECT">MS: Field should be both final and package protected</a></td><td>Malicious code vulnerability</td></tr>
<tr bgcolor="#ffffff"><td><a href="#MS_MUTABLE_ARRAY">MS: Field is a mutable array</a></td><td>Malicious code vulnerability</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#MS_MUTABLE_HASHTABLE">MS: Field is a mutable Hashtable</a></td><td>Malicious code vulnerability</td></tr>
<tr bgcolor="#ffffff"><td><a href="#MS_OOI_PKGPROTECT">MS: Field should be moved out of an interface and made package protected</a></td><td>Malicious code vulnerability</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#MS_PKGPROTECT">MS: Field should be package protected</a></td><td>Malicious code vulnerability</td></tr>
<tr bgcolor="#ffffff"><td><a href="#MS_SHOULD_BE_FINAL">MS: Field isn't final but should be</a></td><td>Malicious code vulnerability</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#DC_DOUBLECHECK">DC: Possible double check of field</a></td><td>Multithreaded correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#DM_MONITOR_WAIT_ON_CONDITION">Dm: Monitor wait() called on Condition</a></td><td>Multithreaded correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#DM_USELESS_THREAD">Dm: A thread was created using the default empty run method</a></td><td>Multithreaded correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#ESync_EMPTY_SYNC">ESync: Empty synchronized block</a></td><td>Multithreaded correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#IS2_INCONSISTENT_SYNC">IS: Inconsistent synchronization</a></td><td>Multithreaded correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#IS_FIELD_NOT_GUARDED">IS: Field not guarded against concurrent access</a></td><td>Multithreaded correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#JLM_JSR166_LOCK_MONITORENTER">JLM: Synchronization performed on java.util.concurrent Lock</a></td><td>Multithreaded correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#LI_LAZY_INIT_STATIC">LI: Incorrect lazy initialization of static field</a></td><td>Multithreaded correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#ML_SYNC_ON_UPDATED_FIELD">ML: Method synchronizes on an updated field</a></td><td>Multithreaded correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#MWN_MISMATCHED_NOTIFY">MWN: Mismatched notify()</a></td><td>Multithreaded correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#MWN_MISMATCHED_WAIT">MWN: Mismatched wait()</a></td><td>Multithreaded correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#NN_NAKED_NOTIFY">NN: Naked notify</a></td><td>Multithreaded correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#NP_SYNC_AND_NULL_CHECK_FIELD">NP: Synchronize and null check on the same field.</a></td><td>Multithreaded correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#NO_NOTIFY_NOT_NOTIFYALL">No: Using notify() rather than notifyAll()</a></td><td>Multithreaded correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#RS_READOBJECT_SYNC">RS: Class's readObject() method is synchronized</a></td><td>Multithreaded correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#RU_INVOKE_RUN">Ru: Invokes run on a thread (did you mean to start it instead?)</a></td><td>Multithreaded correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#SC_START_IN_CTOR">SC: Constructor invokes Thread.start()</a></td><td>Multithreaded correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#SP_SPIN_ON_FIELD">SP: Method spins on field</a></td><td>Multithreaded correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#STCAL_INVOKE_ON_STATIC_CALENDAR_INSTANCE">STCAL: Call to static Calendar</a></td><td>Multithreaded correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#STCAL_INVOKE_ON_STATIC_DATE_FORMAT_INSTANCE">STCAL: Call to static DateFormat</a></td><td>Multithreaded correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#STCAL_STATIC_CALENDAR_INSTANCE">STCAL: Static Calendar</a></td><td>Multithreaded correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#STCAL_STATIC_SIMPLE_DATA_FORMAT_INSTANCE">STCAL: Static DateFormat</a></td><td>Multithreaded correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#SWL_SLEEP_WITH_LOCK_HELD">SWL: Method calls Thread.sleep() with a lock held</a></td><td>Multithreaded correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#TLW_TWO_LOCK_WAIT">TLW: Wait with two locks held</a></td><td>Multithreaded correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#UG_SYNC_SET_UNSYNC_GET">UG: Unsynchronized get method, synchronized set method</a></td><td>Multithreaded correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#UL_UNRELEASED_LOCK">UL: Method does not release lock on all paths</a></td><td>Multithreaded correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#UL_UNRELEASED_LOCK_EXCEPTION_PATH">UL: Method does not release lock on all exception paths</a></td><td>Multithreaded correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#UW_UNCOND_WAIT">UW: Unconditional wait</a></td><td>Multithreaded correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#VO_VOLATILE_REFERENCE_TO_ARRAY">VO: A volatile reference to an array doesn't treat the array elements as volatile</a></td><td>Multithreaded correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#WS_WRITEOBJECT_SYNC">WS: Class's writeObject() method is synchronized but nothing else is</a></td><td>Multithreaded correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#WA_AWAIT_NOT_IN_LOOP">Wa: Condition.await() not in loop </a></td><td>Multithreaded correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#WA_NOT_IN_LOOP">Wa: Wait not in loop </a></td><td>Multithreaded correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#BX_BOXING_IMMEDIATELY_UNBOXED">Bx: Primitive value is boxed and then immediately unboxed</a></td><td>Performance</td></tr>
<tr bgcolor="#ffffff"><td><a href="#BX_BOXING_IMMEDIATELY_UNBOXED_TO_PERFORM_COERCION">Bx: Primitive value is boxed then unboxed to perform primative coercion</a></td><td>Performance</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#DM_BOXED_PRIMITIVE_TOSTRING">Bx: Method allocates a boxed primitive just to call toString</a></td><td>Performance</td></tr>
<tr bgcolor="#ffffff"><td><a href="#DM_FP_NUMBER_CTOR">Bx: Method invokes inefficient floating-point Number constructor; use static valueOf instead</a></td><td>Performance</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#DM_NUMBER_CTOR">Bx: Method invokes inefficient Number constructor; use static valueOf instead</a></td><td>Performance</td></tr>
<tr bgcolor="#ffffff"><td><a href="#DMI_BLOCKING_METHODS_ON_URL">Dm: The equals and hashCode methods of URL are blocking</a></td><td>Performance</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#DMI_COLLECTION_OF_URLS">Dm: Maps and sets of URLs can be performance hogs</a></td><td>Performance</td></tr>
<tr bgcolor="#ffffff"><td><a href="#DM_BOOLEAN_CTOR">Dm: Method invokes inefficient Boolean constructor; use Boolean.valueOf(...) instead</a></td><td>Performance</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#DM_GC">Dm: Explicit garbage collection; extremely dubious except in benchmarking code</a></td><td>Performance</td></tr>
<tr bgcolor="#ffffff"><td><a href="#DM_NEW_FOR_GETCLASS">Dm: Method allocates an object, only to get the class object</a></td><td>Performance</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#DM_NEXTINT_VIA_NEXTDOUBLE">Dm: Use the nextInt method of Random rather than nextDouble to generate a random integer</a></td><td>Performance</td></tr>
<tr bgcolor="#ffffff"><td><a href="#DM_STRING_CTOR">Dm: Method invokes inefficient new String(String) constructor</a></td><td>Performance</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#DM_STRING_EMPTY_EQUALS">Dm: Method invokes inefficient String.equals(""); use String.length() == 0 instead</a></td><td>Performance</td></tr>
<tr bgcolor="#ffffff"><td><a href="#DM_STRING_TOSTRING">Dm: Method invokes toString() method on a String</a></td><td>Performance</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#DM_STRING_VOID_CTOR">Dm: Method invokes inefficient new String() constructor</a></td><td>Performance</td></tr>
<tr bgcolor="#ffffff"><td><a href="#HSC_HUGE_SHARED_STRING_CONSTANT">HSC: Huge string constants is duplicated across multiple class files</a></td><td>Performance</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#ITA_INEFFICIENT_TO_ARRAY">ITA: Method uses toArray() with zero-length array argument</a></td><td>Performance</td></tr>
<tr bgcolor="#ffffff"><td><a href="#SBSC_USE_STRINGBUFFER_CONCATENATION">SBSC: Method concatenates strings using + in a loop</a></td><td>Performance</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#SIC_INNER_SHOULD_BE_STATIC">SIC: Should be a static inner class</a></td><td>Performance</td></tr>
<tr bgcolor="#ffffff"><td><a href="#SIC_INNER_SHOULD_BE_STATIC_ANON">SIC: Could be refactored into a named static inner class</a></td><td>Performance</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#SIC_INNER_SHOULD_BE_STATIC_NEEDS_THIS">SIC: Could be refactored into a static inner class</a></td><td>Performance</td></tr>
<tr bgcolor="#ffffff"><td><a href="#SS_SHOULD_BE_STATIC">SS: Unread field: should this field be static?</a></td><td>Performance</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#UM_UNNECESSARY_MATH">UM: Method calls static Math class method on a constant value</a></td><td>Performance</td></tr>
<tr bgcolor="#ffffff"><td><a href="#UPM_UNCALLED_PRIVATE_METHOD">UPM: Private method is never called</a></td><td>Performance</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#URF_UNREAD_FIELD">UrF: Unread field</a></td><td>Performance</td></tr>
<tr bgcolor="#ffffff"><td><a href="#UUF_UNUSED_FIELD">UuF: Unused field</a></td><td>Performance</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#WMI_WRONG_MAP_ITERATOR">WMI: Inefficient use of keySet iterator instead of entrySet iterator</a></td><td>Performance</td></tr>
<tr bgcolor="#ffffff"><td><a href="#BC_BAD_CAST_TO_ABSTRACT_COLLECTION">BC: Questionable cast to abstract collection </a></td><td>Dodgy</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#BC_BAD_CAST_TO_CONCRETE_COLLECTION">BC: Questionable cast to concrete collection</a></td><td>Dodgy</td></tr>
<tr bgcolor="#ffffff"><td><a href="#BC_UNCONFIRMED_CAST">BC: Unchecked/unconfirmed cast</a></td><td>Dodgy</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#BC_VACUOUS_INSTANCEOF">BC: instanceof will always return true</a></td><td>Dodgy</td></tr>
<tr bgcolor="#ffffff"><td><a href="#CI_CONFUSED_INHERITANCE">CI: Class is final but declares protected field</a></td><td>Dodgy</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#DB_DUPLICATE_BRANCHES">DB: Method uses the same code for two branches</a></td><td>Dodgy</td></tr>
<tr bgcolor="#ffffff"><td><a href="#DB_DUPLICATE_SWITCH_CLAUSES">DB: Method uses the same code for two switch clauses</a></td><td>Dodgy</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#DLS_DEAD_LOCAL_STORE">DLS: Dead store to local variable</a></td><td>Dodgy</td></tr>
<tr bgcolor="#ffffff"><td><a href="#DLS_DEAD_LOCAL_STORE_OF_NULL">DLS: Dead store of null to local variable</a></td><td>Dodgy</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#DMI_HARDCODED_ABSOLUTE_FILENAME">DMI: Code contains a hard coded reference to an absolute pathname</a></td><td>Dodgy</td></tr>
<tr bgcolor="#ffffff"><td><a href="#DMI_NONSERIALIZABLE_OBJECT_WRITTEN">DMI: Non serializable object written to ObjectOutput</a></td><td>Dodgy</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#DMI_USELESS_SUBSTRING">DMI: Invocation of substring(0), which returns the original value</a></td><td>Dodgy</td></tr>
<tr bgcolor="#ffffff"><td><a href="#DMI_THREAD_PASSED_WHERE_RUNNABLE_EXPECTED">Dm: Thread passed where Runnable expected</a></td><td>Dodgy</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#FE_FLOATING_POINT_EQUALITY">FE: Test for floating point equality</a></td><td>Dodgy</td></tr>
<tr bgcolor="#ffffff"><td><a href="#IA_AMBIGUOUS_INVOCATION_OF_INHERITED_OR_OUTER_METHOD">IA: Ambiguous invocation of either an inherited or outer method</a></td><td>Dodgy</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#IC_INIT_CIRCULARITY">IC: Initialization circularity</a></td><td>Dodgy</td></tr>
<tr bgcolor="#ffffff"><td><a href="#ICAST_IDIV_CAST_TO_DOUBLE">ICAST: int division result cast to double or float</a></td><td>Dodgy</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#ICAST_INTEGER_MULTIPLY_CAST_TO_LONG">ICAST: Result of integer multiplication cast to long</a></td><td>Dodgy</td></tr>
<tr bgcolor="#ffffff"><td><a href="#ICAST_QUESTIONABLE_UNSIGNED_RIGHT_SHIFT">ICAST: Unsigned right shift cast to short/byte</a></td><td>Dodgy</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#IM_AVERAGE_COMPUTATION_COULD_OVERFLOW">IM: Computation of average could overflow</a></td><td>Dodgy</td></tr>
<tr bgcolor="#ffffff"><td><a href="#IM_BAD_CHECK_FOR_ODD">IM: Check for oddness that won't work for negative numbers </a></td><td>Dodgy</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#INT_VACUOUS_COMPARISON">INT: Vacuous comparison of integer value</a></td><td>Dodgy</td></tr>
<tr bgcolor="#ffffff"><td><a href="#MTIA_SUSPECT_SERVLET_INSTANCE_FIELD">MTIA: Class extends Servlet class and uses instance variables</a></td><td>Dodgy</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#MTIA_SUSPECT_STRUTS_INSTANCE_FIELD">MTIA: Class extends Struts Action class and uses instance variables</a></td><td>Dodgy</td></tr>
<tr bgcolor="#ffffff"><td><a href="#NP_IMMEDIATE_DEREFERENCE_OF_READLINE">NP: Immediate dereference of the result of readLine()</a></td><td>Dodgy</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#NP_LOAD_OF_KNOWN_NULL_VALUE">NP: Load of known null value</a></td><td>Dodgy</td></tr>
<tr bgcolor="#ffffff"><td><a href="#NP_NULL_ON_SOME_PATH_FROM_RETURN_VALUE">NP: Possible null pointer dereference due to return value of called method</a></td><td>Dodgy</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#PZLA_PREFER_ZERO_LENGTH_ARRAYS">PZLA: Consider returning a zero length array rather than null</a></td><td>Dodgy</td></tr>
<tr bgcolor="#ffffff"><td><a href="#QF_QUESTIONABLE_FOR_LOOP">QF: Complicated, subtle or wrong increment in for-loop </a></td><td>Dodgy</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#RCN_REDUNDANT_COMPARISON_OF_NULL_AND_NONNULL_VALUE">RCN: Redundant comparison of non-null value to null</a></td><td>Dodgy</td></tr>
<tr bgcolor="#ffffff"><td><a href="#RCN_REDUNDANT_COMPARISON_TWO_NULL_VALUES">RCN: Redundant comparison of two null values</a></td><td>Dodgy</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#RCN_REDUNDANT_NULLCHECK_OF_NONNULL_VALUE">RCN: Redundant nullcheck of value known to be non-null</a></td><td>Dodgy</td></tr>
<tr bgcolor="#ffffff"><td><a href="#RCN_REDUNDANT_NULLCHECK_OF_NULL_VALUE">RCN: Redundant nullcheck of value known to be null</a></td><td>Dodgy</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#REC_CATCH_EXCEPTION">REC: Exception is caught when Exception is not thrown</a></td><td>Dodgy</td></tr>
<tr bgcolor="#ffffff"><td><a href="#RI_REDUNDANT_INTERFACES">RI: Class implements same interface as superclass</a></td><td>Dodgy</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#RV_CHECK_FOR_POSITIVE_INDEXOF">RV: Method checks to see if result of String.indexOf is positive</a></td><td>Dodgy</td></tr>
<tr bgcolor="#ffffff"><td><a href="#RV_REM_OF_HASHCODE">RV: Remainder of hashCode could be negative</a></td><td>Dodgy</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#RV_REM_OF_RANDOM_INT">RV: Remainder of 32-bit signed random integer</a></td><td>Dodgy</td></tr>
<tr bgcolor="#ffffff"><td><a href="#SA_LOCAL_SELF_ASSIGNMENT">SA: Self assignment of local variable</a></td><td>Dodgy</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#SF_SWITCH_FALLTHROUGH">SF: Switch statement found where one case falls through to the next case</a></td><td>Dodgy</td></tr>
<tr bgcolor="#ffffff"><td><a href="#ST_WRITE_TO_STATIC_FROM_INSTANCE_METHOD">ST: Write to static field from instance method</a></td><td>Dodgy</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#SE_TRANSIENT_FIELD_OF_NONSERIALIZABLE_CLASS">Se: Transient field of class that isn't Serializable. </a></td><td>Dodgy</td></tr>
<tr bgcolor="#ffffff"><td><a href="#UCF_USELESS_CONTROL_FLOW">UCF: Useless control flow</a></td><td>Dodgy</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#UWF_FIELD_NOT_INITIALIZED_IN_CONSTRUCTOR">UwF: Field not initialized in constructor</a></td><td>Dodgy</td></tr>
<tr bgcolor="#ffffff"><td><a href="#XFB_XML_FACTORY_BYPASS">XFB: Method directly allocates a specific implementation of xml interfaces</a></td><td>Dodgy</td></tr>
</table>
<h2>Descriptions</h2>
<h3><a name="AM_CREATES_EMPTY_JAR_FILE_ENTRY">AM: Creates an empty jar file entry (AM_CREATES_EMPTY_JAR_FILE_ENTRY)</a></h3>
<p>The code calls <code>putNextEntry()</code>, immediately
followed by a call to <code>closeEntry()</code>. This results
in an empty JarFile entry. The contents of the entry
should be written to the JarFile between the calls to
<code>putNextEntry()</code> and
<code>closeEntry()</code>.</p>
<h3><a name="AM_CREATES_EMPTY_ZIP_FILE_ENTRY">AM: Creates an empty zip file entry (AM_CREATES_EMPTY_ZIP_FILE_ENTRY)</a></h3>
<p>The code calls <code>putNextEntry()</code>, immediately
followed by a call to <code>closeEntry()</code>. This results
in an empty ZipFile entry. The contents of the entry
should be written to the ZipFile between the calls to
<code>putNextEntry()</code> and
<code>closeEntry()</code>.</p>
<h3><a name="BC_EQUALS_METHOD_SHOULD_WORK_FOR_ALL_OBJECTS">BC: Equals method should not assume anything about the type of its argument (BC_EQUALS_METHOD_SHOULD_WORK_FOR_ALL_OBJECTS)</a></h3>
<p>
The <code>equals(Object o)</code> method shouldn't make any assumptions
about the type of <code>o</code>. It should simply return
false if <code>o</code> is not the same type as <code>this</code>.
</p>
<h3><a name="DMI_RANDOM_USED_ONLY_ONCE">BC: Random object created and used only once (DMI_RANDOM_USED_ONLY_ONCE)</a></h3>
<p> This code creates a java.util.Random object, uses it to generate one random number, and then discards
the Random object. This produces mediocre quality random numbers and is inefficient.
If possible, rewrite the code so that the Random object is created once and saved, and each time a new random number
is required invoke a method on the existing Random object to obtain it.
</p>
<p>If it is important that the generated Random numbers not be guessable, you <em>must</em> not create a new Random for each random
number; the values are too easily guessable. You should strongly consider using a java.security.SecureRandom instead
(and avoid allocating a new SecureRandom for each random number needed).
</p>
<h3><a name="CN_IDIOM">CN: Class implements Cloneable but does not define or use clone method (CN_IDIOM)</a></h3>
<p>
Class implements Cloneable but does not define or
use the clone method.</p>
<h3><a name="CN_IDIOM_NO_SUPER_CALL">CN: clone method does not call super.clone() (CN_IDIOM_NO_SUPER_CALL)</a></h3>
<p> This non-final class defines a clone() method that does not call super.clone().
If this class ("<i>A</i>") is extended by a subclass ("<i>B</i>"),
and the subclass <i>B</i> calls super.clone(), then it is likely that
<i>B</i>'s clone() method will return an object of type <i>A</i>,
which violates the standard contract for clone().</p>
<p> If all clone() methods call super.clone(), then they are guaranteed
to use Object.clone(), which always returns an object of the correct type.</p>
<h3><a name="CO_ABSTRACT_SELF">Co: Abstract class defines covariant compareTo() method (CO_ABSTRACT_SELF)</a></h3>
<p> This class defines a covariant version of <code>compareTo()</code>.
To correctly override the <code>compareTo()</code> method in the
<code>Comparable</code> interface, the parameter of <code>compareTo()</code>
must have type <code>java.lang.Object</code>.</p>
<h3><a name="CO_SELF_NO_OBJECT">Co: Covariant compareTo() method defined (CO_SELF_NO_OBJECT)</a></h3>
<p> This class defines a covariant version of <code>compareTo()</code>.
To correctly override the <code>compareTo()</code> method in the
<code>Comparable</code> interface, the parameter of <code>compareTo()</code>
must have type <code>java.lang.Object</code>.</p>
<h3><a name="DE_MIGHT_DROP">DE: Method might drop exception (DE_MIGHT_DROP)</a></h3>
<p> 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.</p>
<h3><a name="DE_MIGHT_IGNORE">DE: Method might ignore exception (DE_MIGHT_IGNORE)</a></h3>
<p> 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.</p>
<h3><a name="DP_CREATE_CLASSLOADER_INSIDE_DO_PRIVILEGED">DP: Classloaders should only be created inside doPrivileged block (DP_CREATE_CLASSLOADER_INSIDE_DO_PRIVILEGED)</a></h3>
<p> This code creates a classloader, which requires a security manager.
If this code will be granted security permissions, but might be invoked by code that does not
have security permissions, then the classloader creation needs to occur inside a doPrivileged block.</p>
<h3><a name="DP_DO_INSIDE_DO_PRIVILEGED">DP: Method invoked that should be only be invoked inside a doPrivileged block (DP_DO_INSIDE_DO_PRIVILEGED)</a></h3>
<p> This code invokes a method that requires a security permission check.
If this code will be granted security permissions, but might be invoked by code that does not
have security permissions, then the invocation needs to occur inside a doPrivileged block.</p>
<h3><a name="DM_EXIT">Dm: Method invokes System.exit(...) (DM_EXIT)</a></h3>
<p> 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.</p>
<h3><a name="DM_RUN_FINALIZERS_ON_EXIT">Dm: Method invokes dangerous method runFinalizersOnExit (DM_RUN_FINALIZERS_ON_EXIT)</a></h3>
<p> <em>Never call System.runFinalizersOnExit
or Runtime.runFinalizersOnExit for any reason: they are among the most
dangerous methods in the Java libraries.</em> -- Joshua Bloch</p>
<h3><a name="ES_COMPARING_PARAMETER_STRING_WITH_EQ">ES: Comparison of String parameter using == or != (ES_COMPARING_PARAMETER_STRING_WITH_EQ)</a></h3>
<p>This code compares a <code>java.lang.String</code> parameter for reference
equality using the == or != operators. Requiring callers to
pass only String constants or interned strings to a method is unnecessarily
fragile, and rarely leads to measurable performance gains. Consider
using the <code>equals(Object)</code> method instead.</p>
<h3><a name="ES_COMPARING_STRINGS_WITH_EQ">ES: Comparison of String objects using == or != (ES_COMPARING_STRINGS_WITH_EQ)</a></h3>
<p>This code compares <code>java.lang.String</code> objects for reference
equality using the == or != operators.
Unless both strings are either constants in a source file, or have been
interned using the <code>String.intern()</code> method, the same string
value may be represented by two different String objects. Consider
using the <code>equals(Object)</code> method instead.</p>
<h3><a name="EQ_ABSTRACT_SELF">Eq: Abstract class defines covariant equals() method (EQ_ABSTRACT_SELF)</a></h3>
<p> This class defines a covariant version of <code>equals()</code>.
To correctly override the <code>equals()</code> method in
<code>java.lang.Object</code>, the parameter of <code>equals()</code>
must have type <code>java.lang.Object</code>.</p>
<h3><a name="EQ_COMPARETO_USE_OBJECT_EQUALS">Eq: Class defines compareTo(...) and uses Object.equals() (EQ_COMPARETO_USE_OBJECT_EQUALS)</a></h3>
<p> This class defines a <code>compareTo(...)</code> method but inherits its
<code>equals()</code> method from <code>java.lang.Object</code>.
Generally, the value of compareTo should return zero if and only if
equals returns true. If this is violated, weird and unpredictable
failures will occur in classes such as PriorityQueue.
In Java 5 the PriorityQueue.remove method uses the compareTo method,
while in Java 6 it uses the equals method.
<p>From the JavaDoc for the compareTo method in the Comparable interface:
<blockquote>
It is strongly recommended, but not strictly required that <code>(x.compareTo(y)==0) == (x.equals(y))</code>.
Generally speaking, any class that implements the Comparable interface and violates this condition
should clearly indicate this fact. The recommended language
is "Note: this class has a natural ordering that is inconsistent with equals."
</blockquote>
<h3><a name="EQ_SELF_NO_OBJECT">Eq: Covariant equals() method defined (EQ_SELF_NO_OBJECT)</a></h3>
<p> This class defines a covariant version of <code>equals()</code>.
To correctly override the <code>equals()</code> method in
<code>java.lang.Object</code>, the parameter of <code>equals()</code>
must have type <code>java.lang.Object</code>.</p>
<h3><a name="EQ_SELF_USE_OBJECT">Eq: Covariant equals() method defined, Object.equals(Object) inherited (EQ_SELF_USE_OBJECT)</a></h3>
<p> This class defines a covariant version of the <code>equals()</code>
method, but inherits the normal <code>equals(Object)</code> method
defined in the base <code>java.lang.Object</code> class.
The class should probably define a non-covariant version of <code>equals()</code>.
(I.e., a method with the signature <code>boolean equals(java.lang.Object)</code>.</p>
<h3><a name="FI_EMPTY">FI: Empty finalizer should be deleted (FI_EMPTY)</a></h3>
<p> Empty <code>finalize()</code> methods are useless, so they should
be deleted.</p>
<h3><a name="FI_EXPLICIT_INVOCATION">FI: Explicit invocation of finalizer (FI_EXPLICIT_INVOCATION)</a></h3>
<p> This method contains an explicit invocation of the <code>finalize()</code>
method on an object. Because finalizer methods are supposed to be
executed once, and only by the VM, this is a bad idea.</p>
<p>If a connected set of objects beings finalizable, then the VM will invoke the
finalize method on all the finalizable object, possibly at the same time in different threads.
Thus, it is a particularly bad idea, in the finalize method for a class X, invoke finalize
on objects referenced by X, because they may already be getting finalized in a separate thread.
<h3><a name="FI_FINALIZER_NULLS_FIELDS">FI: Finalizer nulls fields (FI_FINALIZER_NULLS_FIELDS)</a></h3>
<p> This finalizer nulls out fields. This is usually an error, as it does not aid garbage collection,
and the object is going to be garbage collected anyway.
<h3><a name="FI_FINALIZER_ONLY_NULLS_FIELDS">FI: Finalizer only nulls fields (FI_FINALIZER_ONLY_NULLS_FIELDS)</a></h3>
<p> This finalizer does nothing except null out fields. This is completely pointless, and requires that
the object be garbage collected, finalized, and then garbage collected again. You should just remove the finalize
method.
<h3><a name="FI_MISSING_SUPER_CALL">FI: Finalizer does not call superclass finalizer (FI_MISSING_SUPER_CALL)</a></h3>
<p> This <code>finalize()</code> method does not make a call to its
superclass's <code>finalize()</code> method. So, any finalizer
actions defined for the superclass will not be performed.
Add a call to <code>super.finalize()</code>.</p>
<h3><a name="FI_NULLIFY_SUPER">FI: Finalizer nullifies superclass finalizer (FI_NULLIFY_SUPER)</a></h3>
<p> This empty <code>finalize()</code> 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.</p>
<h3><a name="FI_USELESS">FI: Finalizer does nothing but call superclass finalizer (FI_USELESS)</a></h3>
<p> The only thing this <code>finalize()</code> method does is call
the superclass's <code>finalize()</code> method, making it
redundant. Delete it.</p>
<h3><a name="HE_EQUALS_NO_HASHCODE">HE: Class defines equals() but not hashCode() (HE_EQUALS_NO_HASHCODE)</a></h3>
<p> This class overrides <code>equals(Object)</code>, but does not
override <code>hashCode()</code>. Therefore, the class may violate the
invariant that equal objects must have equal hashcodes.</p>
<h3><a name="HE_EQUALS_USE_HASHCODE">HE: Class defines equals() and uses Object.hashCode() (HE_EQUALS_USE_HASHCODE)</a></h3>
<p> This class overrides <code>equals(Object)</code>, but does not
override <code>hashCode()</code>, and inherits the implementation of
<code>hashCode()</code> from <code>java.lang.Object</code> (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.</p>
<p>If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended <code>hashCode</code> implementation to use is:</p>
<pre>public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}</pre>
<h3><a name="HE_HASHCODE_NO_EQUALS">HE: Class defines hashCode() but not equals() (HE_HASHCODE_NO_EQUALS)</a></h3>
<p> This class defines a <code>hashCode()</code> method but not an
<code>equals()</code> method. Therefore, the class may
violate the invariant that equal objects must have equal hashcodes.</p>
<h3><a name="HE_HASHCODE_USE_OBJECT_EQUALS">HE: Class defines hashCode() and uses Object.equals() (HE_HASHCODE_USE_OBJECT_EQUALS)</a></h3>
<p> This class defines a <code>hashCode()</code> method but inherits its
<code>equals()</code> method from <code>java.lang.Object</code>
(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 <code>hashCode()</code> method. (Overriding <code>hashCode()</code>
implies that the object's identity is based on criteria more complicated
than simple reference equality.)</p>
<p>If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
the recommended <code>hashCode</code> implementation to use is:</p>
<p><pre>public int hashCode() {
assert false : "hashCode not designed";
return 42; // any arbitrary constant will do
}</pre></p>
<h3><a name="HE_INHERITS_EQUALS_USE_HASHCODE">HE: Class inherits equals() and uses Object.hashCode() (HE_INHERITS_EQUALS_USE_HASHCODE)</a></h3>
<p> This class inherits <code>equals(Object)</code> from an abstract
superclass, and <code>hashCode()</code> from
<code>java.lang.Object</code> (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.</p>
<p>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 <code>hashCode()</code> method
to throw <code>UnsupportedOperationException</code>.</p>
<h3><a name="IC_SUPERCLASS_USES_SUBCLASS_DURING_INITIALIZATION">IC: Superclass uses subclass during initialization (IC_SUPERCLASS_USES_SUBCLASS_DURING_INITIALIZATION)</a></h3>
<p> During the initialization of a class, the class makes an active use of a subclass.
That subclass will not yet be initialized at the time of this use.
For example, in the following code, <code>foo</code> will be null.</p>
<pre>
public class CircularClassInitialization {
static class InnerClassSingleton extends CircularClassInitialization {
static InnerClassSingleton singleton = new InnerClassSingleton();
}
static CircularClassInitialization foo = InnerClassSingleton.singleton;
}
</pre>
<h3><a name="IMSE_DONT_CATCH_IMSE">IMSE: Dubious catching of IllegalMonitorStateException (IMSE_DONT_CATCH_IMSE)</a></h3>
<p>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).</p>
<h3><a name="ISC_INSTANTIATE_STATIC_CLASS">ISC: Needless instantiation of class that only supplies static methods (ISC_INSTANTIATE_STATIC_CLASS)</a></h3>
<p> 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.</p>
<h3><a name="IT_NO_SUCH_ELEMENT">It: Iterator next() method can't throw NoSuchElement exception (IT_NO_SUCH_ELEMENT)</a></h3>
<p> This class implements the <code>java.util.Iterator</code> interface.
However, its <code>next()</code> method is not capable of throwing
<code>java.util.NoSuchElementException</code>. The <code>next()</code>
method should be changed so it throws <code>NoSuchElementException</code>
if is called when there are no more elements to return.</p>
<h3><a name="J2EE_STORE_OF_NON_SERIALIZABLE_OBJECT_INTO_SESSION">J2EE: Store of non serializable object into HttpSession (J2EE_STORE_OF_NON_SERIALIZABLE_OBJECT_INTO_SESSION)</a></h3>
<p>
This code seems to be storing a non-serializable object into an HttpSession.
If this session is passivated or migrated, an error will result.
</p>
<h3><a name="NP_CLONE_COULD_RETURN_NULL">NP: Clone method may return null (NP_CLONE_COULD_RETURN_NULL)</a></h3>
<p>
This clone method seems to return null in some circumstances, but clone is never
allowed to return a null value. If you are convinced this path is unreachable, throw an AssertionError
instead.
</p>
<h3><a name="NP_EQUALS_SHOULD_HANDLE_NULL_ARGUMENT">NP: equals() method does not check for null argument (NP_EQUALS_SHOULD_HANDLE_NULL_ARGUMENT)</a></h3>
<p>
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 argument. All equals() methods should return
false if passed a null value.
</p>
<h3><a name="NP_TOSTRING_COULD_RETURN_NULL">NP: toString method may return null (NP_TOSTRING_COULD_RETURN_NULL)</a></h3>
<p>
This toString method seems to return null in some circumstances. A liberal reading of the
spec could be interpreted as allowing this, but it is probably a bad idea and could cause
other code to break. Return the empty string or some other appropriate string rather than null.
</p>
<h3><a name="NS_NON_SHORT_CIRCUIT">NS: Questionable use of non-short-circuit logic (NS_NON_SHORT_CIRCUIT)</a></h3>
<p> 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.
<p>See <a href="http://java.sun.com/docs/books/jls/third_edition/html/expressions.html#15.22.2">the Java
Language Specification</a> for details
</p>
<h3><a name="NM_CLASS_NAMING_CONVENTION">Nm: Class names should start with an upper case letter (NM_CLASS_NAMING_CONVENTION)</a></h3>
<p> 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).
</p>
<h3><a name="NM_CLASS_NOT_EXCEPTION">Nm: Class is not derived from an Exception, even though it is named as such (NM_CLASS_NOT_EXCEPTION)</a></h3>
<p> This class is not derived from another exception, but ends with 'Exception'. This will
be confusing to users of this class.</p>
<h3><a name="NM_CONFUSING">Nm: Confusing method names (NM_CONFUSING)</a></h3>
<p> The referenced methods have names that differ only by capitalization.</p>
<h3><a name="NM_FIELD_NAMING_CONVENTION">Nm: Field names should start with an lower case letter (NM_FIELD_NAMING_CONVENTION)</a></h3>
<p>
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.
</p>
<h3><a name="NM_FUTURE_KEYWORD_USED_AS_IDENTIFIER">Nm: Use of identifier that is a keyword in later versions of Java (NM_FUTURE_KEYWORD_USED_AS_IDENTIFIER)</a></h3>
<p>The identifier is a word that is reserversed as a keyword in later versions of Java, and your code will need to be changed
in order to compile it in later versions of Java.</p>
<h3><a name="NM_FUTURE_KEYWORD_USED_AS_MEMBER_IDENTIFIER">Nm: Use of identifier that is a keyword in later versions of Java (NM_FUTURE_KEYWORD_USED_AS_MEMBER_IDENTIFIER)</a></h3>
<p>This identifier is used as a keyword in later versions of Java. This code, and
any code that references this API,
will need to be changed in order to compile it in later versions of Java.</p>
<h3><a name="NM_METHOD_NAMING_CONVENTION">Nm: Method names should start with an lower case letter (NM_METHOD_NAMING_CONVENTION)</a></h3>
<p>
Methods should be verbs, in mixed case with the first letter lowercase, with the first letter of each internal word capitalized.
</p>
<h3><a name="NM_VERY_CONFUSING_INTENTIONAL">Nm: Very confusing method names (but intentional) (NM_VERY_CONFUSING_INTENTIONAL)</a></h3>
<p> The referenced methods have names that differ only by capitalization or the packages of their parameters.
This is very confusing because if the capitalization were
identical then one of the methods would override the other. From the existence of other methods, it
seems that the existence of both of these methods is intentional, but is sure is confusing.
You should try hard to eliminate one of them, unless you are forced to have both due to frozen APIs.
</p>
<h3><a name="ODR_OPEN_DATABASE_RESOURCE">ODR: Method may fail to close database resource (ODR_OPEN_DATABASE_RESOURCE)</a></h3>
<p> 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.
</p>
<h3><a name="ODR_OPEN_DATABASE_RESOURCE_EXCEPTION_PATH">ODR: Method may fail to close database resource on exception (ODR_OPEN_DATABASE_RESOURCE_EXCEPTION_PATH)</a></h3>
<p> 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.</p>
<h3><a name="OS_OPEN_STREAM">OS: Method may fail to close stream (OS_OPEN_STREAM)</a></h3>
<p> The method creates an IO stream object, does not assign it to any
fields, pass it to other methods that might close it,
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 <code>finally</code> block to ensure that streams are
closed.</p>
<h3><a name="OS_OPEN_STREAM_EXCEPTION_PATH">OS: Method may fail to close stream on exception (OS_OPEN_STREAM_EXCEPTION_PATH)</a></h3>
<p> 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 <code>finally</code> block to ensure that streams are
closed.</p>
<h3><a name="RR_NOT_CHECKED">RR: Method ignores results of InputStream.read() (RR_NOT_CHECKED)</a></h3>
<p> This method ignores the return value of one of the variants of
<code>java.io.InputStream.read()</code> 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.</p>
<h3><a name="SR_NOT_CHECKED">RR: Method ignores results of InputStream.skip() (SR_NOT_CHECKED)</a></h3>
<p> This method ignores the return value of
<code>java.io.InputStream.skip()</code> 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.</p>
<h3><a name="SI_INSTANCE_BEFORE_FINALS_ASSIGNED">SI: Static initializer creates instance before all static final fields assigned (SI_INSTANCE_BEFORE_FINALS_ASSIGNED)</a></h3>
<p> The class's static initializer creates an instance of the class
before all of the static final fields are assigned.</p>
<h3><a name="SQL_NONCONSTANT_STRING_PASSED_TO_EXECUTE">SQL: Nonconstant string passed to execute method on an SQL statement (SQL_NONCONSTANT_STRING_PASSED_TO_EXECUTE)</a></h3>
<p>The method invokes the execute method on an SQL statement with a String that seems
to be dynamically generated. Consider using
a prepared statement instead. It is more efficient and less vulnerable to
SQL injection attacks.
</p>
<h3><a name="SQL_PREPARED_STATEMENT_GENERATED_FROM_NONCONSTANT_STRING">SQL: A prepared statement is generated from a nonconstant String (SQL_PREPARED_STATEMENT_GENERATED_FROM_NONCONSTANT_STRING)</a></h3>
<p>The code creates an SQL prepared statement from a nonconstant String.
If unchecked, tainted data from a user is used in building this String, SQL injection could
be used to make the prepared statement do something unexpected and undesirable.
</p>
<h3><a name="SW_SWING_METHODS_INVOKED_IN_SWING_THREAD">SW: Certain swing methods needs to be invoked in Swing thread (SW_SWING_METHODS_INVOKED_IN_SWING_THREAD)</a></h3>
<p>(<a href="http://java.sun.com/developer/JDCTechTips/2003/tt1208.html#1">From JDC Tech Tip</a>): 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.</p>
<h3><a name="SE_BAD_FIELD">Se: Non-transient non-serializable instance field in serializable class (SE_BAD_FIELD)</a></h3>
<p> This Serializable class defines a non-primitive instance field which is neither transient,
Serializable, or <code>java.lang.Object</code>, and does not appear to implement
the <code>Externalizable</code> interface or the
<code>readObject()</code> and <code>writeObject()</code> methods.
Objects of this class will not be deserialized correctly if a non-Serializable
object is stored in this field.</p>
<h3><a name="SE_BAD_FIELD_INNER_CLASS">Se: Non-serializable class has a serializable inner class (SE_BAD_FIELD_INNER_CLASS)</a></h3>
<p> This Serializable class is an inner class of a non-serializable class.
Thus, attempts to serialize it will also attempt to associate instance of the outer
class with which it is associated, leading to a runtime error.
</p>
<p>If possible, making the inner class a static inner class should solve the
problem. Making the outer class serializable might also work, but that would
mean serializing an instance of the inner class would always also serialize the instance
of the outer class, which it often not what you really want.
<h3><a name="SE_BAD_FIELD_STORE">Se: Non-serializable value stored into instance field of a serializable class (SE_BAD_FIELD_STORE)</a></h3>
<p> A non-serializable value is stored into a non-transient field
of a serializable class.</p>
<h3><a name="SE_COMPARATOR_SHOULD_BE_SERIALIZABLE">Se: Comparator doesn't implement Serializable (SE_COMPARATOR_SHOULD_BE_SERIALIZABLE)</a></h3>
<p> This class implements the <code>Comparator</code> interface. You
should consider whether or not it should also implement the <code>Serializable</code>
interface. If a comparator is used to construct an ordered collection
such as a <code>TreeMap</code>, then the <code>TreeMap</code>
will be serializable only if the comparator is also serializable.
As most comparators have little or no state, making them serializable
is generally easy and good defensive programming.
</p>
<h3><a name="SE_INNER_CLASS">Se: Serializable inner class (SE_INNER_CLASS)</a></h3>
<p> This Serializable class is an inner class. Any attempt to serialize
it will also serialize the associated outer instance. The outer instance is serializable,
so this won't fail, but it might serialize a lot more data than intended.
If possible, making the inner class a static inner class (also known as a nested class) should solve the
problem.
<h3><a name="SE_METHOD_MUST_BE_PRIVATE">Se: Method must be private in order for serialization to work (SE_METHOD_MUST_BE_PRIVATE)</a></h3>
<p> This class implements the <code>Serializable</code> interface, and defines a method
for custom serialization/deserialization. But since that method isn't declared private,
it will be silently ignored by the serialization/deserialization API.</p>
<h3><a name="SE_NONFINAL_SERIALVERSIONID">Se: serialVersionUID isn't final (SE_NONFINAL_SERIALVERSIONID)</a></h3>
<p> This class defines a <code>serialVersionUID</code> field that is not final.
The field should be made final
if it is intended to specify
the version UID for purposes of serialization.</p>
<h3><a name="SE_NONLONG_SERIALVERSIONID">Se: serialVersionUID isn't long (SE_NONLONG_SERIALVERSIONID)</a></h3>
<p> This class defines a <code>serialVersionUID</code> field that is not long.
The field should be made long
if it is intended to specify
the version UID for purposes of serialization.</p>
<h3><a name="SE_NONSTATIC_SERIALVERSIONID">Se: serialVersionUID isn't static (SE_NONSTATIC_SERIALVERSIONID)</a></h3>
<p> This class defines a <code>serialVersionUID</code> field that is not static.
The field should be made static
if it is intended to specify
the version UID for purposes of serialization.</p>
<h3><a name="SE_NO_SUITABLE_CONSTRUCTOR">Se: Class is Serializable but its superclass doesn't define a void constructor (SE_NO_SUITABLE_CONSTRUCTOR)</a></h3>
<p> This class implements the <code>Serializable</code> 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.</p>
<h3><a name="SE_NO_SUITABLE_CONSTRUCTOR_FOR_EXTERNALIZATION">Se: Class is Externalizable but doesn't define a void constructor (SE_NO_SUITABLE_CONSTRUCTOR_FOR_EXTERNALIZATION)</a></h3>
<p> This class implements the <code>Externalizable</code> 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.</p>
<h3><a name="SE_READ_RESOLVE_MUST_RETURN_OBJECT">Se: The readResolve method must be declared with a return type
of Object. (SE_READ_RESOLVE_MUST_RETURN_OBJECT)</a></h3>
<p> In order for the readResolve method to be recognized by the serialization
mechanism.
</p>
<h3><a name="SE_TRANSIENT_FIELD_NOT_RESTORED">Se: Transient field that isn't set by deserialization. (SE_TRANSIENT_FIELD_NOT_RESTORED)</a></h3>
<p> This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any
deserialized instance of the class.
</p>
<h3><a name="SE_NO_SERIALVERSIONID">SnVI: Class is Serializable, but doesn't define serialVersionUID (SE_NO_SERIALVERSIONID)</a></h3>
<p> This class implements the <code>Serializable</code> interface, but does
not define a <code>serialVersionUID</code> 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 <code>String.class</code>
will generate a static field <code>class$java$lang$String</code>).
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.</p>
<h3><a name="UI_INHERITANCE_UNSAFE_GETRESOURCE">UI: Usage of GetResource may be unsafe if class is extended (UI_INHERITANCE_UNSAFE_GETRESOURCE)</a></h3>
<p>Calling <code>this.getClass().getResource(...)</code> could give
results other than expected if this class is extended by a class in
another package.</p>
<h3><a name="BC_IMPOSSIBLE_CAST">BC: Impossible cast (BC_IMPOSSIBLE_CAST)</a></h3>
<p>
This cast will always throw a ClassCastException.
</p>
<h3><a name="BC_IMPOSSIBLE_INSTANCEOF">BC: instanceof will always return false (BC_IMPOSSIBLE_INSTANCEOF)</a></h3>
<p>
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.
</p>
<h3><a name="BIT_AND">BIT: Incompatible bit masks (BIT_AND)</a></h3>
<p> 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.</p>
<h3><a name="BIT_AND_ZZ">BIT: Check to see if ((...) & 0) == 0 (BIT_AND_ZZ)</a></h3>
<p> 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.</p>
<h3><a name="BIT_IOR">BIT: Incompatible bit masks (BIT_IOR)</a></h3>
<p> 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.</p>
<p> 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 ("&").</p>
<h3><a name="BIT_IOR_OF_SIGNED_BYTE">BIT: Bitwise OR of signed byte value (BIT_IOR_OF_SIGNED_BYTE)</a></h3>
<p> Loads a value from a byte array and performs a bitwise OR with
that value. Values loaded from a byte array are sign extended to 32 bits
before any any bitwise operations are performed on the value.
Thus, if <code>b[0]</code> contains the value <code>0xff</code>, and
<code>x</code> is initially 0, then the code
<code>((x << 8) | b[0])</code> will sign extend <code>0xff</code>
to get <code>0xffffffff</code>, and thus give the value
<code>0xffffffff</code> as the result.
</p>
<p>In particular, the following code for packing a byte array into an int is badly wrong: </p>
<code>
int result = 0;
for(int i = 0; i < 4; i++)
result = ((result << 8) | b[i]);
</code>
<p>The following idiom will work instead: </p>
<code>
int result = 0;
for(int i = 0; i < 4; i++)
result = ((result << 8) | (b[i] &s; 0xff));
</code>
<h3><a name="BOA_BADLY_OVERRIDDEN_ADAPTER">BOA: Class overrides a method implemented in super class Adapter wrongly (BOA_BADLY_OVERRIDDEN_ADAPTER)</a></h3>
<p> 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.</p>
<h3><a name="BX_UNBOXED_AND_COERCED_FOR_TERNARY_OPERATOR">Bx: Primitive value is unboxed and coerced for ternary operator (BX_UNBOXED_AND_COERCED_FOR_TERNARY_OPERATOR)</a></h3>
<p>A wrapped primative value is unboxed and converted to another primative type as part of the
evaluation of a conditional ternary operator (the <code> b ? e1 : e2</code> operator). The
semantics of Java mandate that if <code>e1</code> and <code>e2</code> are wrapped
numeric values, the values are unboxed and converted/coerced to their common type (e.g,
if <code>e1</code> is of type <code>Integer</code>
and <code>e2</code> is of type <code>Float</code>, then <code>e1</code> is unboxed,
converted to a floating point value, and boxed. See JLS Section 15.25.
</p>
<h3><a name="DLS_OVERWRITTEN_INCREMENT">DLS: Overwritten increment (DLS_OVERWRITTEN_INCREMENT)</a></h3>
<p>
The code performs an increment operation (e.g., <code>i++</code>) and then
immediately overwrites it. For example, <code>i = i++</code> immediately
overwrites the incremented value with the original value.
</p>
<h3><a name="DMI_BAD_MONTH">DMI: Bad constant value for month (DMI_BAD_MONTH)</a></h3>
<p>
This code passes a constant month
value outside the expected range of 0..11 to a method.
</p>
<h3><a name="DMI_CALLING_NEXT_FROM_HASNEXT">DMI: hasNext method invokes next (DMI_CALLING_NEXT_FROM_HASNEXT)</a></h3>
<p>
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.
</p>
<h3><a name="DMI_INVOKING_TOSTRING_ON_ARRAY">DMI: Invocation of toString on an array (DMI_INVOKING_TOSTRING_ON_ARRAY)</a></h3>
<p>
The code invokes toString on an array, which will generate a fairly useless result
such as [C@16f0472. Consider using Arrays.toString to convert the array into a readable
String that gives the contents of the array. See Programming Puzzlers, chapter 3, puzzle 12.
</p>
<h3><a name="DMI_LONG_BITS_TO_DOUBLE_INVOKED_ON_INT">DMI: Double.longBitsToDouble invoked on an int (DMI_LONG_BITS_TO_DOUBLE_INVOKED_ON_INT)</a></h3>
<p> The Double.longBitsToDouble method is invoked, but a 32 bit int value is passed
as an argument. This almostly certainly is not intended and is unlikely
to give the intended result.
</p>
<h3><a name="DMI_ANNOTATION_IS_NOT_VISIBLE_TO_REFLECTION">Dm: Can't use reflection to check for presence of annotation with default retention (DMI_ANNOTATION_IS_NOT_VISIBLE_TO_REFLECTION)</a></h3>
<p> Unless an annotation has itself been annotated with a @Retention other than the default
of source-only retention, the annotation isn't retained in the classfile and can't be observed using reflection
(e.g., by using the isAnnotationPresent method).
.</p>
<h3><a name="EC_ARRAY_AND_NONARRAY">EC: equals() used to compare array and nonarray (EC_ARRAY_AND_NONARRAY)</a></h3>
<p>
This method invokes the .equals(Object o) to compare an array and a reference that doesn't seem
to be an array. If things being compared are of different types, they are guaranteed to be unequal
and the comparison is almost certainly an error. Even if they are both arrays, the equals method
on arrays only determines of the two arrays are the same object.
To compare the
contents of the arrays, use java.util.Arrays.equals(Object[], Object[]).
</p>
<h3><a name="EC_BAD_ARRAY_COMPARE">EC: Invocation of equals() on an array, which is equivalent to == (EC_BAD_ARRAY_COMPARE)</a></h3>
<p>
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[]).
</p>
<h3><a name="EC_NULL_ARG">EC: Call to equals() with null argument (EC_NULL_ARG)</a></h3>
<p> 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 <code>false</code>.</p>
<h3><a name="EC_UNRELATED_CLASS_AND_INTERFACE">EC: Call to equals() comparing unrelated class and interface (EC_UNRELATED_CLASS_AND_INTERFACE)</a></h3>
<p>
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.
</p>
<h3><a name="EC_UNRELATED_INTERFACES">EC: Call to equals() comparing different interface types (EC_UNRELATED_INTERFACES)</a></h3>
<p> 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.
</p>
<h3><a name="EC_UNRELATED_TYPES">EC: Call to equals() comparing different types (EC_UNRELATED_TYPES)</a></h3>
<p> 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.
</p>
<h3><a name="EQ_DONT_DEFINE_EQUALS_FOR_ENUM">Eq: Covariant equals() method defined for enum (EQ_DONT_DEFINE_EQUALS_FOR_ENUM)</a></h3>
<p> This class defines an enumeration, and equality on enumerations are defined
using object identity. Definine a covariant equals method for an enumeration
value is exceptionally bad practice, since it would likely result
in having two different enumeration values that compare as equals using
the covariant enum method, and as not equal when compared normally.
Don't do it.
</p>
<h3><a name="FE_TEST_IF_EQUAL_TO_NOT_A_NUMBER">FE: Doomed test for equality to NaN (FE_TEST_IF_EQUAL_TO_NOT_A_NUMBER)</a></h3>
<p>
This code checks to see if a floating point value is equal to the special
Not A Number value (e.g., <code>if (x == Double.NaN)</code>). However,
because of the special semantics of <code>NaN</code>, no value
is equal to <code>Nan</code>, including <code>NaN</code>. Thus,
<code>x == Double.NaN</code> always evaluates to false.
To check to see if a value contained in <code>x</code>
is the special Not A Number value, use
<code>Double.isNaN(x)</code> (or <code>Float.isNaN(x)</code> if
<code>x</code> is floating point precision).
</p>
<h3><a name="GC_UNRELATED_TYPES">GC: No relationship between generic parameter and method argument (GC_UNRELATED_TYPES)</a></h3>
<p> This call to a generic container's method contains an argument
with a different class type from that of the container's parameter.
Therefore, it is unlikely that the container contains any objects
with the same type as the method argument used here.
</p>
<h3><a name="HE_USE_OF_UNHASHABLE_CLASS">HE: Use of class without a hashCode() method in a hashed data structure (HE_USE_OF_UNHASHABLE_CLASS)</a></h3>
<p> A class defines an equals(Object) method but not a hashCode() method,
and thus doesn't fulfill the requirement that equal Objects have equal hashCodes.
An instance of this class is used in a hash data structure, making the need to
fix this problem of highest importance.
<h3><a name="ICAST_BAD_SHIFT_AMOUNT">ICAST: Integer shift by an amount not in the range 0..31 (ICAST_BAD_SHIFT_AMOUNT)</a></h3>
<p>
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.
</p>
<h3><a name="ICAST_INT_CAST_TO_DOUBLE_PASSED_TO_CEIL">ICAST: int value cast to double and then passed to Math.ceil (ICAST_INT_CAST_TO_DOUBLE_PASSED_TO_CEIL)</a></h3>
<p>
This code converts an int 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.
</p>
<h3><a name="ICAST_INT_CAST_TO_FLOAT_PASSED_TO_ROUND">ICAST: int value cast to float and then passed to Math.round (ICAST_INT_CAST_TO_FLOAT_PASSED_TO_ROUND)</a></h3>
<p>
This code converts an int value to a float precision
floating point number and then
passing the result to the Math.round() function, which returns the int/long closest
to the argument. This operation should always be a no-op,
since the converting an integer to a float should give a number with no fractional part.
It is likely that the operation that generated the value to be passed
to Math.round was intended to be performed using
floating point arithmetic.
</p>
<h3><a name="IJU_ASSERT_METHOD_INVOKED_FROM_RUN_METHOD">IJU: JUnit assertion in run method will not be noticed by JUnit (IJU_ASSERT_METHOD_INVOKED_FROM_RUN_METHOD)</a></h3>
<p> A JUnit assertion is performed in a run method. Failed JUnit assertions
just result in exceptions being thrown.
Thus, if this exception occurs in a thread other than the thread that invokes
the test method, the exception will terminate the thread but not result
in the test failing.
</p>
<h3><a name="IJU_BAD_SUITE_METHOD">IJU: TestCase declares a bad suite method (IJU_BAD_SUITE_METHOD)</a></h3>
<p> Class is a JUnit TestCase and defines a suite() method.
However, the suite method needs to be declared as either
<pre>public static junit.framework.Test suite()</pre>
or
<pre>public static junit.framework.TestSuite suite()</pre>
</p>
<h3><a name="IJU_NO_TESTS">IJU: TestCase has no tests (IJU_NO_TESTS)</a></h3>
<p> Class is a JUnit TestCase but has not implemented any test methods</p>
<h3><a name="IJU_SETUP_NO_SUPER">IJU: TestCase implements setUp but doesn't call super.setUp() (IJU_SETUP_NO_SUPER)</a></h3>
<p> Class is a JUnit TestCase and implements the setUp method. The setUp method should call
super.setUp(), but doesn't.</p>
<h3><a name="IJU_SUITE_NOT_STATIC">IJU: TestCase implements a non-static suite method (IJU_SUITE_NOT_STATIC)</a></h3>
<p> Class is a JUnit TestCase and implements the suite() method.
The suite method should be declared as being static, but isn't.</p>
<h3><a name="IJU_TEARDOWN_NO_SUPER">IJU: TestCase implements tearDown but doesn't call super.tearDown() (IJU_TEARDOWN_NO_SUPER)</a></h3>
<p> Class is a JUnit TestCase and implements the tearDown method. The tearDown method should call
super.tearDown(), but doesn't.</p>
<h3><a name="IL_CONTAINER_ADDED_TO_ITSELF">IL: A container is added to itself (IL_CONTAINER_ADDED_TO_ITSELF)</a></h3>
<p>A container is added to itself. As a result, computing the hashCode of this
set will throw a StackOverflowException.
</p>
<h3><a name="IL_INFINITE_LOOP">IL: An apparent infinite loop (IL_INFINITE_LOOP)</a></h3>
<p>This loop doesn't seem to have a way to terminate (other than by perhaps
throwing an exception).</p>
<h3><a name="IL_INFINITE_RECURSIVE_LOOP">IL: An apparent infinite recursive loop (IL_INFINITE_RECURSIVE_LOOP)</a></h3>
<p>This method unconditionally invokes itself. This would seem to indicate
an infinite recursive loop that will result in a stack overflow.</p>
<h3><a name="IM_MULTIPLYING_RESULT_OF_IREM">IM: Integer multiply of result of integer remainder (IM_MULTIPLYING_RESULT_OF_IREM)</a></h3>
<p>
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).
</p>
<h3><a name="INT_BAD_COMPARISON_WITH_NONNEGATIVE_VALUE">INT: Bad comparison of nonnegative value with negative constant (INT_BAD_COMPARISON_WITH_NONNEGATIVE_VALUE)</a></h3>
<p> This code compares a value that is guaranteed to be non-negative with a negative constant.
</p>
<h3><a name="INT_BAD_COMPARISON_WITH_SIGNED_BYTE">INT: Bad comparison of signed byte (INT_BAD_COMPARISON_WITH_SIGNED_BYTE)</a></h3>
<p> Signed bytes can only have a value in the range -128 to 127. Comparing
a signed byte with a value outside that range is vacuous and likely to be incorrect.
To convert a signed byte <code>b</code> to an unsigned value in the range 0..255,
use <code>0xff & b</code>
</p>
<h3><a name="INT_BAD_REM_BY_1">INT: Integer remainder modulo 1 (INT_BAD_REM_BY_1)</a></h3>
<p> Any expression (exp % 1) is guaranteed to always return zero.
Did you mean (exp & 1) or (exp % 2) instead?
</p>
<h3><a name="IP_PARAMETER_IS_DEAD_BUT_OVERWRITTEN">IP: A parameter is dead upon entry to a method but overwritten (IP_PARAMETER_IS_DEAD_BUT_OVERWRITTEN)</a></h3>
<p>
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.
</p>
<h3><a name="JCIP_FIELD_ISNT_FINAL_IN_IMMUTABLE_CLASS">JCIP: Fields of immutable classes should be final (JCIP_FIELD_ISNT_FINAL_IN_IMMUTABLE_CLASS)</a></h3>
<p> The class is annotated with net.jcip.annotations.Immutable, and the rules for that annotation require
that all fields are final.
.</p>
<h3><a name="MF_CLASS_MASKS_FIELD">MF: Class defines field that masks a superclass field (MF_CLASS_MASKS_FIELD)</a></h3>
<p> 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.</p>
<h3><a name="MF_METHOD_MASKS_FIELD">MF: Method defines a variable that obscures a field (MF_METHOD_MASKS_FIELD)</a></h3>
<p> 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.</p>
<h3><a name="NP_ALWAYS_NULL">NP: Null pointer dereference (NP_ALWAYS_NULL)</a></h3>
<p> A null pointer is dereferenced here. This will lead to a
<code>NullPointerException</code> when the code is executed.</p>
<h3><a name="NP_ALWAYS_NULL_EXCEPTION">NP: Null pointer dereference in method on exception path (NP_ALWAYS_NULL_EXCEPTION)</a></h3>
<p> A pointer which is null on an exception path is dereferenced here.
This will lead to a <code>NullPointerException</code> when the code is executed.
Note that because FindBugs currently does not prune infeasible exception paths,
this may be a false warning.</p>
<p> Also note that FindBugs considers the default case of a switch statement to
be an exception path, since the default case is often infeasible.</p>
<h3><a name="NP_ARGUMENT_MIGHT_BE_NULL">NP: Method does not check for null argument (NP_ARGUMENT_MIGHT_BE_NULL)</a></h3>
<p>
A parameter to this method has been identified as a value that should
always be checked to see whether or not it is null, but it is being dereferenced
without a preceding null check.
</p>
<h3><a name="NP_GUARANTEED_DEREF">NP: Null value is guaranteed to be dereferenced (NP_GUARANTEED_DEREF)</a></h3>
<p>
There is a statement or branch that if executed guarantees that
a value is null at this point, and that
value that is guaranteed to be dereferenced
(except on forward paths involving runtime exceptions).
</p>
<h3><a name="NP_GUARANTEED_DEREF_ON_EXCEPTION_PATH">NP: Value is null and guaranteed to be dereferenced on exception path (NP_GUARANTEED_DEREF_ON_EXCEPTION_PATH)</a></h3>
<p>
There is a statement or branch on an exception path
that if executed guarantees that
a value is null at this point, and that
value that is guaranteed to be dereferenced
(except on forward paths involving runtime exceptions).
</p>
<h3><a name="NP_NONNULL_PARAM_VIOLATION">NP: Method call passes null to a nonnull parameter (NP_NONNULL_PARAM_VIOLATION)</a></h3>
<p>
This method passes a null value as the parameter of a method which
must be nonnull. Either this parameter has been explicitly marked
as @Nonnull, or analysis has determined that this parameter is
always deferenced.
</p>
<h3><a name="NP_NONNULL_RETURN_VIOLATION">NP: Method may return null, but is declared @NonNull (NP_NONNULL_RETURN_VIOLATION)</a></h3>
<p>
This method may return a null value, but the method (or a superclass method
which it overrides) is declared to return @NonNull.
</p>
<h3><a name="NP_NULL_INSTANCEOF">NP: A known null value is checked to see if it is an instance of a type (NP_NULL_INSTANCEOF)</a></h3>
<p>
This instanceof test will always return false, since the value being checked is guaranteed to be null.
Although this is safe, make sure it isn't
an indication of some misunderstanding or some other logic error.
</p>
<h3><a name="NP_NULL_ON_SOME_PATH">NP: Possible null pointer dereference (NP_NULL_ON_SOME_PATH)</a></h3>
<p> A reference value dereferenced here might be null at runtime.
This may lead to a <code>NullPointerException</code> when the code is executed.</p>
<h3><a name="NP_NULL_ON_SOME_PATH_EXCEPTION">NP: Possible null pointer dereference in method on exception path (NP_NULL_ON_SOME_PATH_EXCEPTION)</a></h3>
<p> A reference value which is null on some exception control path is
dereferenced here. This may lead to a <code>NullPointerException</code>
when the code is executed.
Note that because FindBugs currently does not prune infeasible exception paths,
this may be a false warning.</p>
<p> Also note that FindBugs considers the default case of a switch statement to
be an exception path, since the default case is often infeasible.</p>
<h3><a name="NP_NULL_PARAM_DEREF">NP: Method call passes null for unconditionally dereferenced parameter (NP_NULL_PARAM_DEREF)</a></h3>
<p>
This method call passes a null value to a method which might
dereference it unconditionally.
</p>
<h3><a name="NP_NULL_PARAM_DEREF_ALL_TARGETS_DANGEROUS">NP: Method call passes null for unconditionally dereferenced parameter (NP_NULL_PARAM_DEREF_ALL_TARGETS_DANGEROUS)</a></h3>
<p>
A possibly-null value is passed at a call site where all known
target methods will unconditionally dereference it.
This is very likely to result in a null pointer exception.
</p>
<h3><a name="NP_NULL_PARAM_DEREF_NONVIRTUAL">NP: Non-virtual method call passes null for unconditionally dereferenced parameter (NP_NULL_PARAM_DEREF_NONVIRTUAL)</a></h3>
<p>
A possibly-null value is passed to a method which unconditionally
dereferences it. This will almost certainly result in a null pointer exception.
</p>
<h3><a name="NP_STORE_INTO_NONNULL_FIELD">NP: Store of null value into field annotated NonNull (NP_STORE_INTO_NONNULL_FIELD)</a></h3>
<p> A value that could be null is stored into a field that has been annotated as NonNull. </p>
<h3><a name="NP_UNWRITTEN_FIELD">NP: Read of unwritten field (NP_UNWRITTEN_FIELD)</a></h3>
<p> The program is dereferencing a field that does not seem to ever have a non-null value written to it.
Dereferencing this value will generate a null pointer exception.
</p>
<h3><a name="NS_DANGEROUS_NON_SHORT_CIRCUIT">NS: Potentially dangerous use of non-short-circuit logic (NS_DANGEROUS_NON_SHORT_CIRCUIT)</a></h3>
<p> This code seems to be using non-short-circuit logic (e.g., &
or |)
rather than short-circuit logic (&& or ||). In addition,
it seem possible that, depending on the value of the left hand side, you might not
want to evaluate the right hand side (because it would have side effects, could cause an exception
or could be expensive.</p>
<p>
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.
</p>
<p>See <a href="http://java.sun.com/docs/books/jls/third_edition/html/expressions.html#15.22.2">the Java
Language Specification</a> for details
</p>
<h3><a name="NM_BAD_EQUAL">Nm: Class defines equal(); should it be equals()? (NM_BAD_EQUAL)</a></h3>
<p> This class defines a method <code>equal(Object)</code>. This method does
not override the <code>equals(Object)</code> method in <code>java.lang.Object</code>,
which is probably what was intended.</p>
<h3><a name="NM_LCASE_HASHCODE">Nm: Class defines hashcode(); should it be hashCode()? (NM_LCASE_HASHCODE)</a></h3>
<p> This class defines a method called <code>hashcode()</code>. This method
does not override the <code>hashCode()</code> method in <code>java.lang.Object</code>,
which is probably what was intended.</p>
<h3><a name="NM_LCASE_TOSTRING">Nm: Class defines tostring(); should it be toString()? (NM_LCASE_TOSTRING)</a></h3>
<p> This class defines a method called <code>tostring()</code>. This method
does not override the <code>toString()</code> method in <code>java.lang.Object</code>,
which is probably what was intended.</p>
<h3><a name="NM_METHOD_CONSTRUCTOR_CONFUSION">Nm: Apparent method/constructor confusion (NM_METHOD_CONSTRUCTOR_CONFUSION)</a></h3>
<p> 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 void return value.
If you had accidently defined this method, realized the mistake, defined a proper constructor
but can't get rid of this method due to backwards compatibility, deprecate the method.
</p>
<h3><a name="NM_VERY_CONFUSING">Nm: Very confusing method names (NM_VERY_CONFUSING)</a></h3>
<p> The referenced methods have names that differ only by capitalization or the packages of their parameters.
This is very confusing because if the capitalization and parameter package names were
identical then one of the methods would override the other.
</p>
<h3><a name="QBA_QUESTIONABLE_BOOLEAN_ASSIGNMENT">QBA: Method assigns boolean literal in boolean expression (QBA_QUESTIONABLE_BOOLEAN_ASSIGNMENT)</a></h3>
<p>
This method assigns a literal boolean value (true or false) to a boolean variable inside
an if or while expression. Most probably this was supposed to be a boolean comparison using
==, not an assignment using =.
</p>
<h3><a name="RC_REF_COMPARISON">RC: Suspicious reference comparison (RC_REF_COMPARISON)</a></h3>
<p> 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.</p>
<h3><a name="RCN_REDUNDANT_NULLCHECK_WOULD_HAVE_BEEN_A_NPE">RCN: Nullcheck of value previously dereferenced (RCN_REDUNDANT_NULLCHECK_WOULD_HAVE_BEEN_A_NPE)</a></h3>
<p> A value is checked here to see whether it is null, but this value can't
be null because it was previously dereferenced and if it were null a null pointer
exception would have occurred at the earlier dereference.
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.</p>
<h3><a name="RE_BAD_SYNTAX_FOR_REGULAR_EXPRESSION">RE: Invalid syntax for regular expression (RE_BAD_SYNTAX_FOR_REGULAR_EXPRESSION)</a></h3>
<p>
The code here uses a regular expression that is invalid according to the syntax
for regular expressions. This statement will throw a PatternSyntaxException when
executed.
</p>
<h3><a name="RE_CANT_USE_FILE_SEPARATOR_AS_REGULAR_EXPRESSION">RE: File.separator used for regular expression (RE_CANT_USE_FILE_SEPARATOR_AS_REGULAR_EXPRESSION)</a></h3>
<p>
The code here uses <code>File.separator</code>
where a regular expression is required. This will fail on Windows
platforms, where the <code>File.separator</code> is a backslash, which is interpreted in a
regular expression as an escape character. Amoung other options, you can just use
<code>File.separatorChar=='\\' & "\\\\" : File.separator</code> instead of
<code>File.separator</code>
</p>
<h3><a name="RE_POSSIBLE_UNINTENDED_PATTERN">RE: "." used for regular expression (RE_POSSIBLE_UNINTENDED_PATTERN)</a></h3>
<p>
A String function is being invoked and "." is being passed
to a parameter that takes a regular expression as an argument. Is this what you intended?
For example
s.replaceAll(".", "/") will return a String in which <em>every</em>
character has been replaced by a / character.
</p>
<h3><a name="RV_01_TO_INT">RV: Random value from 0 to 1 is coerced to the integer 0 (RV_01_TO_INT)</a></h3>
<p>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 the Random.nextInt(n) method.
</p>
<h3><a name="RV_ABSOLUTE_VALUE_OF_HASHCODE">RV: Bad attempt to compute absolute value of signed 32-bit hashcode (RV_ABSOLUTE_VALUE_OF_HASHCODE)</a></h3>
<p> This code generates a hashcode and then computes
the absolute value of that hashcode. If the hashcode
is <code>Integer.MIN_VALUE</code>, then the result will be negative as well (since
<code>Math.abs(Integer.MIN_VALUE) == Integer.MIN_VALUE</code>).
</p>
<h3><a name="RV_ABSOLUTE_VALUE_OF_RANDOM_INT">RV: Bad attempt to compute absolute value of signed 32-bit random integer (RV_ABSOLUTE_VALUE_OF_RANDOM_INT)</a></h3>
<p> This code generates a random signed integer and then computes
the absolute value of that random integer. If the number returned by the random number
generator is <code>Integer.MIN_VALUE</code>, then the result will be negative as well (since
<code>Math.abs(Integer.MIN_VALUE) == Integer.MIN_VALUE</code>).
</p>
<h3><a name="RV_DONT_JUST_NULL_CHECK_READLINE">RV: Method discards result of readLine after checking if it is nonnull (RV_DONT_JUST_NULL_CHECK_READLINE)</a></h3>
<p> 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.</p>
<h3><a name="RV_RETURN_VALUE_IGNORED">RV: Method ignores return value (RV_RETURN_VALUE_IGNORED)</a></h3>
<p> 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,</p>
<blockquote>
<pre>
String dateString = getHeaderField(name);
dateString.trim();
</pre>
</blockquote>
<p>the programmer seems to be thinking that the trim() method 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: </p>
<blockquote>
<pre>
String dateString = getHeaderField(name);
dateString = dateString.trim();
</pre>
</blockquote>
<h3><a name="SA_FIELD_DOUBLE_ASSIGNMENT">SA: Double assignment of field (SA_FIELD_DOUBLE_ASSIGNMENT)</a></h3>
<p> This method contains a double assignment of a field; e.g.
</p>
<pre>
int x,y;
public void foo() {
x = x = 17;
}
</pre>
<p>Assigning to a field twice is useless, and may indicate a logic error or typo.</p>
<h3><a name="SA_FIELD_SELF_ASSIGNMENT">SA: Self assignment of field (SA_FIELD_SELF_ASSIGNMENT)</a></h3>
<p> This method contains a self assignment of a field; e.g.
</p>
<pre>
int x;
public void foo() {
x = x;
}
</pre>
<p>Such assignments are useless, and may indicate a logic error or typo.</p>
<h3><a name="SA_FIELD_SELF_COMPARISON">SA: Self comparison of field with itself (SA_FIELD_SELF_COMPARISON)</a></h3>
<p> This method compares a field with itself, and may indicate a typo or
a logic error. Make sure that you are comparing the right things.
</p>
<h3><a name="SA_FIELD_SELF_COMPUTATION">SA: Nonsensical self computation involving a field (e.g., x & x) (SA_FIELD_SELF_COMPUTATION)</a></h3>
<p> This method performs a nonsensical computation of a field with another
reference to the same field (e.g., x&x or x-x). Because of the nature
of the computation, this operation doesn't seem to make sense,
and may indicate a typo or
a logic error. Double check the computation.
</p>
<h3><a name="SA_LOCAL_DOUBLE_ASSIGNMENT">SA: Double assignment of local variable (SA_LOCAL_DOUBLE_ASSIGNMENT)</a></h3>
<p> This method contains a double assignment of a local variable; e.g.
</p>
<pre>
public void foo() {
int x,y;
x = x = 17;
}
</pre>
<p>Assigning the same value to a variable twice is useless, and may indicate a logic error or typo.</p>
<h3><a name="SA_LOCAL_SELF_COMPARISON">SA: Self comparison of value with itself (SA_LOCAL_SELF_COMPARISON)</a></h3>
<p> This method compares a local variable with itself, and may indicate a typo or
a logic error. Make sure that you are comparing the right things.
</p>
<h3><a name="SA_LOCAL_SELF_COMPUTATION">SA: Nonsensical self computation involving a variable (e.g., x & x) (SA_LOCAL_SELF_COMPUTATION)</a></h3>
<p> This method performs a nonsensical computation of a local variable with another
reference to the same variable (e.g., x&x or x-x). Because of the nature
of the computation, this operation doesn't seem to make sense,
and may indicate a typo or
a logic error. Double check the computation.
</p>
<h3><a name="SF_DEAD_STORE_DUE_TO_SWITCH_FALLTHROUGH">SF: Dead store due to switch statement fall through (SF_DEAD_STORE_DUE_TO_SWITCH_FALLTHROUGH)</a></h3>
<p> A value stored in the previous switch case is overwritten here due to a switch fall through. It is likely that
you forgot to put a break or return at the end of the previous case.
</p>
<h3><a name="SIO_SUPERFLUOUS_INSTANCEOF">SIO: Unnecessary type check done using instanceof operator (SIO_SUPERFLUOUS_INSTANCEOF)</a></h3>
<p> Type check performed using the instanceof operator where it can be statically determined whether the object
is of the type requested. </p>
<h3><a name="SQL_BAD_PREPARED_STATEMENT_ACCESS">SQL: Method attempts to access a prepared statement parameter with index 0 (SQL_BAD_PREPARED_STATEMENT_ACCESS)</a></h3>
<p> A call to a setXXX method of a prepared statement was made where the
parameter index is 0. As parameter indexes start at index 1, this is always a mistake.</p>
<h3><a name="SQL_BAD_RESULTSET_ACCESS">SQL: Method attempts to access a result set field with index 0 (SQL_BAD_RESULTSET_ACCESS)</a></h3>
<p> 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.</p>
<h3><a name="STI_INTERRUPTED_ON_CURRENTTHREAD">STI: Unneeded use of currentThread() call, to call interrupted() (STI_INTERRUPTED_ON_CURRENTTHREAD)</a></h3>
<p>
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().
</p>
<h3><a name="STI_INTERRUPTED_ON_UNKNOWNTHREAD">STI: Static Thread.interrupted() method invoked on thread instance (STI_INTERRUPTED_ON_UNKNOWNTHREAD)</a></h3>
<p>
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.
</p>
<h3><a name="UCF_USELESS_CONTROL_FLOW_NEXT_LINE">UCF: Useless control flow to next line (UCF_USELESS_CONTROL_FLOW_NEXT_LINE)</a></h3>
<p> This method contains a useless control flow statement in which control
flow follows to the same or following line regardless of whether or not
the branch is taken.
Often, this is caused by inadvertently using an empty statement as the
body of an <code>if</code> statement, e.g.:</p>
<pre>
if (argv.length == 1);
System.out.println("Hello, " + argv[0]);
</pre>
<h3><a name="UMAC_UNCALLABLE_METHOD_OF_ANONYMOUS_CLASS">UMAC: Uncallable method defined in anonymous class (UMAC_UNCALLABLE_METHOD_OF_ANONYMOUS_CLASS)</a></h3>
<p> This anonymous class defined a method that is not directly invoked and does not override
a method in a superclass. Since methods in other classes cannot directly invoke methods
declared in an anonymous class, it seems that this method is uncallable. The method
might simply be dead code, but it is also possible that the method is intended to
override a method declared in a superclass, and due to an typo or other error the method does not,
in fact, override the method it is intended to.
</p>
<h3><a name="UR_UNINIT_READ">UR: Uninitialized read of field in constructor (UR_UNINIT_READ)</a></h3>
<p> 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.</p>
<h3><a name="UWF_NULL_FIELD">UwF: Field only ever set to null (UWF_NULL_FIELD)</a></h3>
<p> 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.</p>
<h3><a name="UWF_UNWRITTEN_FIELD">UwF: Unwritten field (UWF_UNWRITTEN_FIELD)</a></h3>
<p> 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.</p>
<h3><a name="VA_PRIMITIVE_ARRAY_PASSED_TO_OBJECT_VARARG">VA: Primitive array passed to function expecting a variable number of object arguments (VA_PRIMITIVE_ARRAY_PASSED_TO_OBJECT_VARARG)</a></h3>
<p>
This code passes a primitive array to a function that takes a variable number of object arguments.
This creates an array of length one to hold the primitive array and passes it to the function.
</p>
<h3><a name="DM_CONVERT_CASE">Dm: Consider using Locale parameterized version of invoked method (DM_CONVERT_CASE)</a></h3>
<p> 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 </p>
<table><tr><td>String.toUpperCase( Locale l )</td></tr><tr><td>String.toLowerCase( Locale l )</td></tr></table>
<p>versions instead.</p>
<h3><a name="EI_EXPOSE_REP">EI: May expose internal representation by returning reference to mutable object (EI_EXPOSE_REP)</a></h3>
<p> 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.</p>
<h3><a name="EI_EXPOSE_REP2">EI2: May expose internal representation by incorporating reference to mutable object (EI_EXPOSE_REP2)</a></h3>
<p> 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.</p>
<h3><a name="FI_PUBLIC_SHOULD_BE_PROTECTED">FI: Finalizer should be protected, not public (FI_PUBLIC_SHOULD_BE_PROTECTED)</a></h3>
<p> A class's <code>finalize()</code> method should have protected access,
not public.</p>
<h3><a name="EI_EXPOSE_STATIC_REP2">MS: May expose internal static state by storing a mutable object into a static field (EI_EXPOSE_STATIC_REP2)</a></h3>
<p> 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.</p>
<h3><a name="MS_CANNOT_BE_FINAL">MS: Field isn't final and can't be protected from malicious code (MS_CANNOT_BE_FINAL)</a></h3>
<p>
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.</p>
<h3><a name="MS_EXPOSE_REP">MS: Public static method may expose internal representation by returning array (MS_EXPOSE_REP)</a></h3>
<p> 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.</p>
<h3><a name="MS_FINAL_PKGPROTECT">MS: Field should be both final and package protected (MS_FINAL_PKGPROTECT)</a></h3>
<p>
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.</p>
<h3><a name="MS_MUTABLE_ARRAY">MS: Field is a mutable array (MS_MUTABLE_ARRAY)</a></h3>
<p> 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.</p>
<h3><a name="MS_MUTABLE_HASHTABLE">MS: Field is a mutable Hashtable (MS_MUTABLE_HASHTABLE)</a></h3>
<p>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.</p>
<h3><a name="MS_OOI_PKGPROTECT">MS: Field should be moved out of an interface and made package protected (MS_OOI_PKGPROTECT)</a></h3>
<p>
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.</p>
<h3><a name="MS_PKGPROTECT">MS: Field should be package protected (MS_PKGPROTECT)</a></h3>
<p> A mutable static field could be changed by malicious code or
by accident.
The field could be made package protected to avoid
this vulnerability.</p>
<h3><a name="MS_SHOULD_BE_FINAL">MS: Field isn't final but should be (MS_SHOULD_BE_FINAL)</a></h3>
<p>
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.</p>
<h3><a name="DC_DOUBLECHECK">DC: Possible double check of field (DC_DOUBLECHECK)</a></h3>
<p> 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
<a href="http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html"
>http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html</a>.</p>
<h3><a name="DM_MONITOR_WAIT_ON_CONDITION">Dm: Monitor wait() called on Condition (DM_MONITOR_WAIT_ON_CONDITION)</a></h3>
<p>
This method calls <code>wait()</code> on a
<code>java.util.concurrent.locks.Condition</code> object.
Waiting for a <code>Condition</code> should be done using one of the <code>await()</code>
methods defined by the <code>Condition</code> interface.
</p>
<h3><a name="DM_USELESS_THREAD">Dm: A thread was created using the default empty run method (DM_USELESS_THREAD)</a></h3>
<p>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.
</p>
<h3><a name="ESync_EMPTY_SYNC">ESync: Empty synchronized block (ESync_EMPTY_SYNC)</a></h3>
<p> The code contains an empty synchronized block:</p>
<pre>
synchronized() {}
</pre>
<p>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.
</p>
<h3><a name="IS2_INCONSISTENT_SYNC">IS: Inconsistent synchronization (IS2_INCONSISTENT_SYNC)</a></h3>
<p> 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
</p>
<ol>
<li> The class contains a mix of locked and unlocked accesses,</li>
<li> At least one locked access was performed by one of the class's own methods, and</li>
<li> 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</li>
</ol>
<p> 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.</p>
<p> You can select the nodes labeled "Unsynchronized access" to show the
code locations where the detector believed that a field was accessed
without synchronization.</p>
<p> 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.</p>
<p> 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.</p>
<h3><a name="IS_FIELD_NOT_GUARDED">IS: Field not guarded against concurrent access (IS_FIELD_NOT_GUARDED)</a></h3>
<p> This field is annotated with net.jcip.annotations.GuardedBy,
but can be accessed in a way that seems to violate the annotation.</p>
<h3><a name="JLM_JSR166_LOCK_MONITORENTER">JLM: Synchronization performed on java.util.concurrent Lock (JLM_JSR166_LOCK_MONITORENTER)</a></h3>
<p> This method performs synchronization on an implementation of
<code>java.util.concurrent.locks.Lock</code>. You should use
the <code>lock()</code> and <code>unlock()</code> methods instead.
</p>
<h3><a name="LI_LAZY_INIT_STATIC">LI: Incorrect lazy initialization of static field (LI_LAZY_INIT_STATIC)</a></h3>
<p> 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,
<em>if the method can be called by multiple threads</em>.
You can make the field volatile to correct the problem.
For more information, see the
<a href="http://www.cs.umd.edu/~pugh/java/memoryModel/">Java Memory Model web site</a>.
</p>
<h3><a name="ML_SYNC_ON_UPDATED_FIELD">ML: Method synchronizes on an updated field (ML_SYNC_ON_UPDATED_FIELD)</a></h3>
<p> 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.</p>
<h3><a name="MWN_MISMATCHED_NOTIFY">MWN: Mismatched notify() (MWN_MISMATCHED_NOTIFY)</a></h3>
<p> 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 <code>IllegalMonitorStateException</code> being thrown.</p>
<h3><a name="MWN_MISMATCHED_WAIT">MWN: Mismatched wait() (MWN_MISMATCHED_WAIT)</a></h3>
<p> This method calls Object.wait() without obviously holding a lock
on the object. Calling wait() without a lock held will result in
an <code>IllegalMonitorStateException</code> being thrown.</p>
<h3><a name="NN_NAKED_NOTIFY">NN: Naked notify (NN_NAKED_NOTIFY)</a></h3>
<p> A call to <code>notify()</code> or <code>notifyAll()</code>
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.</p>
<p> 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.</p>
<h3><a name="NP_SYNC_AND_NULL_CHECK_FIELD">NP: Synchronize and null check on the same field. (NP_SYNC_AND_NULL_CHECK_FIELD)</a></h3>
<p>Since field is synchronized on, it seems not likely to be null.
If it is null and then synchronized on a NullPointerException will be
thrown and the check would be pointless. Better to synchronize on
another field.</p>
<h3><a name="NO_NOTIFY_NOT_NOTIFYALL">No: Using notify() rather than notifyAll() (NO_NOTIFY_NOT_NOTIFYALL)</a></h3>
<p> This method calls <code>notify()</code> rather than <code>notifyAll()</code>.
Java monitors are often used for multiple conditions. Calling <code>notify()</code>
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.</p>
<h3><a name="RS_READOBJECT_SYNC">RS: Class's readObject() method is synchronized (RS_READOBJECT_SYNC)</a></h3>
<p> This serializable class defines a <code>readObject()</code> which is
synchronized. By definition, an object created by deserialization
is only reachable by one thread, and thus there is no need for
<code>readObject()</code> to be synchronized. If the <code>readObject()</code>
method itself is causing the object to become visible to another thread,
that is an example of very dubious coding style.</p>
<h3><a name="RU_INVOKE_RUN">Ru: Invokes run on a thread (did you mean to start it instead?) (RU_INVOKE_RUN)</a></h3>
<p> This method explicitly invokes <code>run()</code> on an object.
In general, classes implement the <code>Runnable</code> interface because
they are going to have their <code>run()</code> method invoked in a new thread,
in which case <code>Thread.start()</code> is the right method to call.</p>
<h3><a name="SC_START_IN_CTOR">SC: Constructor invokes Thread.start() (SC_START_IN_CTOR)</a></h3>
<p> 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.</p>
<h3><a name="SP_SPIN_ON_FIELD">SP: Method spins on field (SP_SPIN_ON_FIELD)</a></h3>
<p> 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).</p>
<h3><a name="STCAL_INVOKE_ON_STATIC_CALENDAR_INSTANCE">STCAL: Call to static Calendar (STCAL_INVOKE_ON_STATIC_CALENDAR_INSTANCE)</a></h3>
<p>Even though the JavaDoc does not contain a hint about it, Calendars are inherently unsafe for multihtreaded use.
The detector has found a call to an instance of Calendar that has been obtained via a static
field. This looks suspicous.</p>
<p>For more information on this see <a href="http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6231579">Sun Bug #6231579</a>
and <a href="http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6178997">Sun Bug #6178997</a>.</p>
<h3><a name="STCAL_INVOKE_ON_STATIC_DATE_FORMAT_INSTANCE">STCAL: Call to static DateFormat (STCAL_INVOKE_ON_STATIC_DATE_FORMAT_INSTANCE)</a></h3>
<p>As the JavaDoc states, DateFormats are inherently unsafe for multithreaded use.
The detector has found a call to an instance of DateFormat that has been obtained via a static
field. This looks suspicous.</p>
<p>For more information on this see <a href="http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6231579">Sun Bug #6231579</a>
and <a href="http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6178997">Sun Bug #6178997</a>.</p>
<h3><a name="STCAL_STATIC_CALENDAR_INSTANCE">STCAL: Static Calendar (STCAL_STATIC_CALENDAR_INSTANCE)</a></h3>
<p>Even though the JavaDoc does not contain a hint about it, Calendars are inherently unsafe for multihtreaded use.
Sharing a single instance across thread boundaries without proper synchronization will result in erratic behavior of the
application. Under 1.4 problems seem to surface less often than under Java 5 where you will probably see
random ArrayIndexOutOfBoundsExceptions or IndexOutOfBoundsExceptions in sun.util.calendar.BaseCalendar.getCalendarDateFromFixedDate().</p>
<p>You may also experience serialization problems.</p>
<p>Using an instance field is recommended.</p>
<p>For more information on this see <a href="http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6231579">Sun Bug #6231579</a>
and <a href="http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6178997">Sun Bug #6178997</a>.</p>
<h3><a name="STCAL_STATIC_SIMPLE_DATA_FORMAT_INSTANCE">STCAL: Static DateFormat (STCAL_STATIC_SIMPLE_DATA_FORMAT_INSTANCE)</a></h3>
<p>As the JavaDoc states, DateFormats are inherently unsafe for multithreaded use.
Sharing a single instance across thread boundaries without proper synchronization will result in erratic behavior of the
application.</p>
<p>You may also experience serialization problems.</p>
<p>Using an instance field is recommended.</p>
<p>For more information on this see <a href="http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6231579">Sun Bug #6231579</a>
and <a href="http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6178997">Sun Bug #6178997</a>.</p>
<h3><a name="SWL_SLEEP_WITH_LOCK_HELD">SWL: Method calls Thread.sleep() with a lock held (SWL_SLEEP_WITH_LOCK_HELD)</a></h3>
<p>
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.
</p>
<h3><a name="TLW_TWO_LOCK_WAIT">TLW: Wait with two locks held (TLW_TWO_LOCK_WAIT)</a></h3>
<p> 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.</p>
<h3><a name="UG_SYNC_SET_UNSYNC_GET">UG: Unsynchronized get method, synchronized set method (UG_SYNC_SET_UNSYNC_GET)</a></h3>
<p> 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.</p>
<h3><a name="UL_UNRELEASED_LOCK">UL: Method does not release lock on all paths (UL_UNRELEASED_LOCK)</a></h3>
<p> This method acquires a JSR-166 (<code>java.util.concurrent</code>) 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:
</p>
<pre>
Lock l = ...;
l.lock();
try {
// do something
} finally {
l.unlock();
}
</pre>
<h3><a name="UL_UNRELEASED_LOCK_EXCEPTION_PATH">UL: Method does not release lock on all exception paths (UL_UNRELEASED_LOCK_EXCEPTION_PATH)</a></h3>
<p> This method acquires a JSR-166 (<code>java.util.concurrent</code>) 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:
</p>
<pre>
Lock l = ...;
l.lock();
try {
// do something
} finally {
l.unlock();
}
</pre>
<h3><a name="UW_UNCOND_WAIT">UW: Unconditional wait (UW_UNCOND_WAIT)</a></h3>
<p> This method contains a call to <code>java.lang.Object.wait()</code> which
is not guarded by conditional control flow. The code should
verify that condition it intends to wait for is not already satisfied
before calling wait; any previous notifications will be ignored.
</p>
<h3><a name="VO_VOLATILE_REFERENCE_TO_ARRAY">VO: A volatile reference to an array doesn't treat the array elements as volatile (VO_VOLATILE_REFERENCE_TO_ARRAY)</a></h3>
<p>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).</p>
<h3><a name="WS_WRITEOBJECT_SYNC">WS: Class's writeObject() method is synchronized but nothing else is (WS_WRITEOBJECT_SYNC)</a></h3>
<p> This class has a <code>writeObject()</code> method which is synchronized;
however, no other method of the class is synchronized.</p>
<h3><a name="WA_AWAIT_NOT_IN_LOOP">Wa: Condition.await() not in loop (WA_AWAIT_NOT_IN_LOOP)</a></h3>
<p> This method contains a call to <code>java.util.concurrent.await()</code>
(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.</p>
<h3><a name="WA_NOT_IN_LOOP">Wa: Wait not in loop (WA_NOT_IN_LOOP)</a></h3>
<p> This method contains a call to <code>java.lang.Object.wait()</code>
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.</p>
<h3><a name="BX_BOXING_IMMEDIATELY_UNBOXED">Bx: Primitive value is boxed and then immediately unboxed (BX_BOXING_IMMEDIATELY_UNBOXED)</a></h3>
<p>A primitive is boxed, and then immediately unboxed. This probably is due to a manual
boxing in a place where an unboxed value is required, thus forcing the compiler
to immediately undue the work of the boxing.
</p>
<h3><a name="BX_BOXING_IMMEDIATELY_UNBOXED_TO_PERFORM_COERCION">Bx: Primitive value is boxed then unboxed to perform primative coercion (BX_BOXING_IMMEDIATELY_UNBOXED_TO_PERFORM_COERCION)</a></h3>
<p>A primitive boxed value constructed and then immediately converted into a different primitive type
(e.g., <code>new Double(d).intValue()</code>). Just perform direct primitive coercion (e.g., <code>(int) d</code>).</p>
<h3><a name="DM_BOXED_PRIMITIVE_TOSTRING">Bx: Method allocates a boxed primitive just to call toString (DM_BOXED_PRIMITIVE_TOSTRING)</a></h3>
<p>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,</p>
<table>
<tr><th>Replace...</th><th>With this...</th></tr>
<tr><td>new Integer(1).toString()</td><td>Integer.toString(1)</td></tr>
<tr><td>new Long(1).toString()</td><td>Long.toString(1)</td></tr>
<tr><td>new Float(1.0).toString()</td><td>Float.toString(1.0)</td></tr>
<tr><td>new Double(1.0).toString()</td><td>Double.toString(1.0)</td></tr>
<tr><td>new Byte(1).toString()</td><td>Byte.toString(1)</td></tr>
<tr><td>new Short(1).toString()</td><td>Short.toString(1)</td></tr>
<tr><td>new Boolean(true).toString()</td><td>Boolean.toString(true)</td></tr>
</table>
<h3><a name="DM_FP_NUMBER_CTOR">Bx: Method invokes inefficient floating-point Number constructor; use static valueOf instead (DM_FP_NUMBER_CTOR)</a></h3>
<p>
Using <code>new Double(double)</code> is guaranteed to always result in a new object whereas
<code>Double.valueOf(double)</code> allows caching of values to be done by the compiler, class library, or JVM.
Using of cached values avoids object allocation and the code will be faster.
</p>
<p>
Unless the class must be compatible with JVMs predating Java 1.5,
use either autoboxing or the <code>valueOf()</code> method when creating instances of <code>Double</code> and <code>Float</code>.
</p>
<h3><a name="DM_NUMBER_CTOR">Bx: Method invokes inefficient Number constructor; use static valueOf instead (DM_NUMBER_CTOR)</a></h3>
<p>
Using <code>new Integer(int)</code> is guaranteed to always result in a new object whereas
<code>Integer.valueOf(int)</code> allows caching of values to be done by the compiler, class library, or JVM.
Using of cached values avoids object allocation and the code will be faster.
</p>
<p>
Values between -128 and 127 are guaranteed to have corresponding cached instances
and using <code>valueOf</code> is approximately 3.5 times faster than using constructor.
For values outside the constant range the performance of both styles is the same.
</p>
<p>
Unless the class must be compatible with JVMs predating Java 1.5,
use either autoboxing or the <code>valueOf()</code> method when creating instances of
<code>Long</code>, <code>Integer</code>, <code>Short</code>, <code>Character</code>, and <code>Byte</code>.
</p>
<h3><a name="DMI_BLOCKING_METHODS_ON_URL">Dm: The equals and hashCode methods of URL are blocking (DMI_BLOCKING_METHODS_ON_URL)</a></h3>
<p> The equals and hashCode
method of URL perform domain name resolution, this can result in a big performance hit.
See <a href="http://michaelscharf.blogspot.com/2006/11/javaneturlequals-and-hashcode-make.html">http://michaelscharf.blogspot.com/2006/11/javaneturlequals-and-hashcode-make.html</a> for more information.
Consider using <code>java.net.URI</code> instead.
</p>
<h3><a name="DMI_COLLECTION_OF_URLS">Dm: Maps and sets of URLs can be performance hogs (DMI_COLLECTION_OF_URLS)</a></h3>
<p> This method or field is or uses a Map or Set of URLs. Since both the equals and hashCode
method of URL perform domain name resolution, this can result in a big performance hit.
See <a href="http://michaelscharf.blogspot.com/2006/11/javaneturlequals-and-hashcode-make.html">http://michaelscharf.blogspot.com/2006/11/javaneturlequals-and-hashcode-make.html</a> for more information.
Consider using <code>java.net.URI</code> instead.
</p>
<h3><a name="DM_BOOLEAN_CTOR">Dm: Method invokes inefficient Boolean constructor; use Boolean.valueOf(...) instead (DM_BOOLEAN_CTOR)</a></h3>
<p> Creating new instances of <code>java.lang.Boolean</code> wastes
memory, since <code>Boolean</code> objects are immutable and there are
only two useful values of this type. Use the <code>Boolean.valueOf()</code>
method (or Java 1.5 autoboxing) to create <code>Boolean</code> objects instead.</p>
<h3><a name="DM_GC">Dm: Explicit garbage collection; extremely dubious except in benchmarking code (DM_GC)</a></h3>
<p> Code explicitly invokes garbage collection.
Except for specific use in benchmarking, this is very dubious.</p>
<p>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.</p>
<h3><a name="DM_NEW_FOR_GETCLASS">Dm: Method allocates an object, only to get the class object (DM_NEW_FOR_GETCLASS)</a></h3>
<p>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.</p>
<h3><a name="DM_NEXTINT_VIA_NEXTDOUBLE">Dm: Use the nextInt method of Random rather than nextDouble to generate a random integer (DM_NEXTINT_VIA_NEXTDOUBLE)</a></h3>
<p>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).
</p>
<h3><a name="DM_STRING_CTOR">Dm: Method invokes inefficient new String(String) constructor (DM_STRING_CTOR)</a></h3>
<p> Using the <code>java.lang.String(String)</code> constructor wastes memory
because the object so constructed will be functionally indistinguishable
from the <code>String</code> passed as a parameter. Just use the
argument <code>String</code> directly.</p>
<h3><a name="DM_STRING_EMPTY_EQUALS">Dm: Method invokes inefficient String.equals(""); use String.length() == 0 instead (DM_STRING_EMPTY_EQUALS)</a></h3>
<p> 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.</p>
<h3><a name="DM_STRING_TOSTRING">Dm: Method invokes toString() method on a String (DM_STRING_TOSTRING)</a></h3>
<p> Calling <code>String.toString()</code> is just a redundant operation.
Just use the String.</p>
<h3><a name="DM_STRING_VOID_CTOR">Dm: Method invokes inefficient new String() constructor (DM_STRING_VOID_CTOR)</a></h3>
<p> Creating a new <code>java.lang.String</code> object using the
no-argument constructor wastes memory because the object so created will
be functionally indistinguishable from the empty string constant
<code>""</code>. Java guarantees that identical string constants
will be represented by the same <code>String</code> object. Therefore,
you should just use the empty string constant directly.</p>
<h3><a name="HSC_HUGE_SHARED_STRING_CONSTANT">HSC: Huge string constants is duplicated across multiple class files (HSC_HUGE_SHARED_STRING_CONSTANT)</a></h3>
<p>
A large String constant is duplicated across multiple class files.
This is likely because a final field is initialized to a String constant, and the Java language
mandates that all references to a final field from other classes be inlined into
that classfile. See <a href="http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6447475">JDK bug 6447475</a>
for a description of an occurrence of this bug in the JDK and how resolving it reduced
the size of the JDK by 1 megabyte.
</p>
<h3><a name="ITA_INEFFICIENT_TO_ARRAY">ITA: Method uses toArray() with zero-length array argument (ITA_INEFFICIENT_TO_ARRAY)</a></h3>
<p> 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
<code>myCollection.toArray(new Foo[myCollection.size()])</code>
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.</p>
<h3><a name="SBSC_USE_STRINGBUFFER_CONCATENATION">SBSC: Method concatenates strings using + in a loop (SBSC_USE_STRINGBUFFER_CONCATENATION)</a></h3>
<p> 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. </p>
<p>Better performance can be obtained by using
a StringBuffer (or StringBuilder in Java 1.5) explicitly.</p>
<p> For example:</p>
<pre>
// 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();
</pre>
<h3><a name="SIC_INNER_SHOULD_BE_STATIC">SIC: Should be a static inner class (SIC_INNER_SHOULD_BE_STATIC)</a></h3>
<p> 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 static.
</p>
<h3><a name="SIC_INNER_SHOULD_BE_STATIC_ANON">SIC: Could be refactored into a named static inner class (SIC_INNER_SHOULD_BE_STATIC_ANON)</a></h3>
<p> 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 <em>static</em> 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.</p>
<h3><a name="SIC_INNER_SHOULD_BE_STATIC_NEEDS_THIS">SIC: Could be refactored into a static inner class (SIC_INNER_SHOULD_BE_STATIC_NEEDS_THIS)</a></h3>
<p> 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 <em>static</em> 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.</p>
<h3><a name="SS_SHOULD_BE_STATIC">SS: Unread field: should this field be static? (SS_SHOULD_BE_STATIC)</a></h3>
<p> This class contains an instance final field that
is initialized to a compile-time static value.
Consider making the field static.</p>
<h3><a name="UM_UNNECESSARY_MATH">UM: Method calls static Math class method on a constant value (UM_UNNECESSARY_MATH)</a></h3>
<p> 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:
</p>
<table>
<tr>
<th>Method</th> <th>Parameter</th>
</tr>
<tr>
<td>abs</td> <td>-any-</td>
</tr>
<tr>
<td>acos</td> <td>0.0 or 1.0</td>
</tr>
<tr>
<td>asin</td> <td>0.0 or 1.0</td>
</tr>
<tr>
<td>atan</td> <td>0.0 or 1.0</td>
</tr>
<tr>
<td>atan2</td> <td>0.0</td>
</tr>
<tr>
<td>cbrt</td> <td>0.0 or 1.0</td>
</tr>
<tr>
<td>ceil</td> <td>-any-</td>
</tr>
<tr>
<td>cos</td> <td>0.0</td>
</tr>
<tr>
<td>cosh</td> <td>0.0</td>
</tr>
<tr>
<td>exp</td> <td>0.0 or 1.0</td>
</tr>
<tr>
<td>expm1</td> <td>0.0</td>
</tr>
<tr>
<td>floor</td> <td>-any-</td>
</tr>
<tr>
<td>log</td> <td>0.0 or 1.0</td>
</tr>
<tr>
<td>log10</td> <td>0.0 or 1.0</td>
</tr>
<tr>
<td>rint</td> <td>-any-</td>
</tr>
<tr>
<td>round</td> <td>-any-</td>
</tr>
<tr>
<td>sin</td> <td>0.0</td>
</tr>
<tr>
<td>sinh</td> <td>0.0</td>
</tr>
<tr>
<td>sqrt</td> <td>0.0 or 1.0</td>
</tr>
<tr>
<td>tan</td> <td>0.0</td>
</tr>
<tr>
<td>tanh</td> <td>0.0</td>
</tr>
<tr>
<td>toDegrees</td> <td>0.0 or 1.0</td>
</tr>
<tr>
<td>toRadians</td> <td>0.0</td>
</tr>
</table>
<h3><a name="UPM_UNCALLED_PRIVATE_METHOD">UPM: Private method is never called (UPM_UNCALLED_PRIVATE_METHOD)</a></h3>
<p> 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.
</p>
<h3><a name="URF_UNREAD_FIELD">UrF: Unread field (URF_UNREAD_FIELD)</a></h3>
<p> This field is never read. Consider removing it from the class.</p>
<h3><a name="UUF_UNUSED_FIELD">UuF: Unused field (UUF_UNUSED_FIELD)</a></h3>
<p> This field is never used. Consider removing it from the class.</p>
<h3><a name="WMI_WRONG_MAP_ITERATOR">WMI: Inefficient use of keySet iterator instead of entrySet iterator (WMI_WRONG_MAP_ITERATOR)</a></h3>
<p> 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.</p>
<h3><a name="BC_BAD_CAST_TO_ABSTRACT_COLLECTION">BC: Questionable cast to abstract collection (BC_BAD_CAST_TO_ABSTRACT_COLLECTION)</a></h3>
<p>
This code casts a Collection to an abstract collection
(such as <code>List</code>, <code>Set</code>, or <code>Map</code>).
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.
</p>
<h3><a name="BC_BAD_CAST_TO_CONCRETE_COLLECTION">BC: Questionable cast to concrete collection (BC_BAD_CAST_TO_CONCRETE_COLLECTION)</a></h3>
<p>
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.
</p>
<h3><a name="BC_UNCONFIRMED_CAST">BC: Unchecked/unconfirmed cast (BC_UNCONFIRMED_CAST)</a></h3>
<p>
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.
</p>
<h3><a name="BC_VACUOUS_INSTANCEOF">BC: instanceof will always return true (BC_VACUOUS_INSTANCEOF)</a></h3>
<p>
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.
</p>
<h3><a name="CI_CONFUSED_INHERITANCE">CI: Class is final but declares protected field (CI_CONFUSED_INHERITANCE)</a></h3>
<p>
This class is declared to be final, but declares fields to be protected. Since the class
is final, it can not be derived from, and the use of protected is confusing. The access
modifier for the field should be changed to private or public to represent the true
use for the field.
</p>
<h3><a name="DB_DUPLICATE_BRANCHES">DB: Method uses the same code for two branches (DB_DUPLICATE_BRANCHES)</a></h3>
<p>
This method uses the same code to implement two branches of a conditional branch.
Check to ensure that this isn't a coding mistake.
</p>
<h3><a name="DB_DUPLICATE_SWITCH_CLAUSES">DB: Method uses the same code for two switch clauses (DB_DUPLICATE_SWITCH_CLAUSES)</a></h3>
<p>
This method uses the same code to implement two clauses of a switch statement.
This could be a case of duplicate code, but it might also indicate
a coding mistake.
</p>
<h3><a name="DLS_DEAD_LOCAL_STORE">DLS: Dead store to local variable (DLS_DEAD_LOCAL_STORE)</a></h3>
<p>
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.
</p>
<p>
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.
</p>
<h3><a name="DLS_DEAD_LOCAL_STORE_OF_NULL">DLS: Dead store of null to local variable (DLS_DEAD_LOCAL_STORE_OF_NULL)</a></h3>
<p>The code stores null into a local variable, and stored value is not
read. This store may have been introduced in assist the garbage collector, but
as of Java SE 6.0, this is no longer needed or useful.
</p>
<h3><a name="DMI_HARDCODED_ABSOLUTE_FILENAME">DMI: Code contains a hard coded reference to an absolute pathname (DMI_HARDCODED_ABSOLUTE_FILENAME)</a></h3>
<p>This code constructs a File object using a hard coded to an absolute pathname
(e.g., <code>new File("/home/dannyc/workspace/j2ee/src/share/com/sun/enterprise/deployment");</code>
</p>
<h3><a name="DMI_NONSERIALIZABLE_OBJECT_WRITTEN">DMI: Non serializable object written to ObjectOutput (DMI_NONSERIALIZABLE_OBJECT_WRITTEN)</a></h3>
<p>
This code seems to be passing a non-serializable object to the ObjectOutput.writeObject method.
If the object is, indeed, non-serializable, an error will result.
</p>
<h3><a name="DMI_USELESS_SUBSTRING">DMI: Invocation of substring(0), which returns the original value (DMI_USELESS_SUBSTRING)</a></h3>
<p>
This code invokes substring(0) on a String, which returns the original value.
</p>
<h3><a name="DMI_THREAD_PASSED_WHERE_RUNNABLE_EXPECTED">Dm: Thread passed where Runnable expected (DMI_THREAD_PASSED_WHERE_RUNNABLE_EXPECTED)</a></h3>
<p> A Thread object is passed as a parameter to a method where
a Runnable is expected. This is rather unusual, and may indicate a logic error
or cause unexpected behavior.
</p>
<h3><a name="FE_FLOATING_POINT_EQUALITY">FE: Test for floating point equality (FE_FLOATING_POINT_EQUALITY)</a></h3>
<p>
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:
<code>if ( Math.abs(x - y) < .0000001 )</code>.
See the Java Language Specification, section 4.2.4.
</p>
<h3><a name="IA_AMBIGUOUS_INVOCATION_OF_INHERITED_OR_OUTER_METHOD">IA: Ambiguous invocation of either an inherited or outer method (IA_AMBIGUOUS_INVOCATION_OF_INHERITED_OR_OUTER_METHOD)</a></h3>
<p> An inner class is invoking a method that could be resolved to either a inherited method or a method defined in an outer class. By the Java semantics,
it will be resolved to invoke the inherited method, but this may not be want
you intend. If you really intend to invoke the inherited method,
invoke it by invoking the method on super (e.g., invoke super.foo(17)), and
thus it will be clear to other readers of your code and to FindBugs
that you want to invoke the inherited method, not the method in the outer class.
</p>
<h3><a name="IC_INIT_CIRCULARITY">IC: Initialization circularity (IC_INIT_CIRCULARITY)</a></h3>
<p> 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.</p>
<h3><a name="ICAST_IDIV_CAST_TO_DOUBLE">ICAST: int division result cast to double or float (ICAST_IDIV_CAST_TO_DOUBLE)</a></h3>
<p>
This code casts the result of an integer division operation to double or
float.
Doing division on integers truncates the result
to the integer value closest to zero. 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 <em>before</em> performing the division. Here is an example:
</p>
<blockquote>
<pre>
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;
</pre>
</blockquote>
<h3><a name="ICAST_INTEGER_MULTIPLY_CAST_TO_LONG">ICAST: Result of integer multiplication cast to long (ICAST_INTEGER_MULTIPLY_CAST_TO_LONG)</a></h3>
<p>
This code performs integer multiply and then converts the result to a long,
as in:
<code>
<pre>
long convertDaysToMilliseconds(int days) { return 1000*3600*24*days; }
</pre></code>
If the multiplication is done using long arithmetic, you can avoid
the possibility that the result will overflow. For example, you
could fix the above code to:
<code>
<pre>
long convertDaysToMilliseconds(int days) { return 1000L*3600*24*days; }
</pre></code>
or
<code>
<pre>
static final long MILLISECONDS_PER_DAY = 24L*3600*1000;
long convertDaysToMilliseconds(int days) { return days * MILLISECONDS_PER_DAY; }
</pre></code>
</p>
<h3><a name="ICAST_QUESTIONABLE_UNSIGNED_RIGHT_SHIFT">ICAST: Unsigned right shift cast to short/byte (ICAST_QUESTIONABLE_UNSIGNED_RIGHT_SHIFT)</a></h3>
<p>
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).
</p>
<h3><a name="IM_AVERAGE_COMPUTATION_COULD_OVERFLOW">IM: Computation of average could overflow (IM_AVERAGE_COMPUTATION_COULD_OVERFLOW)</a></h3>
<p>The code computes the average of two integers using either division or signed right shift,
and then uses the result as the index of an array.
If the values being averaged are very large, this can overflow (resulting in the computation
of a negative average). Assuming that the result is intended to be nonnegative, you
can use an unsigned right shift instead. In other words, rather that using <code>(low+high)/2</code>,
use <code>(low+high) >>> 1</code>
</p>
<p>This bug exists in many earlier implementations of binary search and merge sort.
Martin Buchholz <a href="http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6412541">found and fixed it</a>
in the JDK libraries, and Joshua Bloch
<a href="http://googleresearch.blogspot.com/2006/06/extra-extra-read-all-about-it-nearly.html">widely
publicized the bug pattern</a>.
</p>
<h3><a name="IM_BAD_CHECK_FOR_ODD">IM: Check for oddness that won't work for negative numbers (IM_BAD_CHECK_FOR_ODD)</a></h3>
<p>
The code uses x % 2 == 1 to check to see if a value is odd, but this won't work
for negative numbers (e.g., (-5) % 2 == -1). If this code is intending to check
for oddness, consider using x & 1 == 1, or x % 2 != 0.
</p>
<h3><a name="INT_VACUOUS_COMPARISON">INT: Vacuous comparison of integer value (INT_VACUOUS_COMPARISON)</a></h3>
<p> There is an integer comparison that always returns
the same value (e.g., x <= Integer.MAX_VALUE).
</p>
<h3><a name="MTIA_SUSPECT_SERVLET_INSTANCE_FIELD">MTIA: Class extends Servlet class and uses instance variables (MTIA_SUSPECT_SERVLET_INSTANCE_FIELD)</a></h3>
<p>
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.
</p>
<h3><a name="MTIA_SUSPECT_STRUTS_INSTANCE_FIELD">MTIA: Class extends Struts Action class and uses instance variables (MTIA_SUSPECT_STRUTS_INSTANCE_FIELD)</a></h3>
<p>
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.
</p>
<h3><a name="NP_IMMEDIATE_DEREFERENCE_OF_READLINE">NP: Immediate dereference of the result of readLine() (NP_IMMEDIATE_DEREFERENCE_OF_READLINE)</a></h3>
<p> 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.
</p>
<h3><a name="NP_LOAD_OF_KNOWN_NULL_VALUE">NP: Load of known null value (NP_LOAD_OF_KNOWN_NULL_VALUE)</a></h3>
<p> The variable referenced at this point is known to be null due to an earlier
check against null. Although this is valid, it might be a mistake (perhaps you
intended to refer to a different variable, or perhaps the earlier check to see if the
variable is null should have been a check to see if it was nonnull.
</p>
<h3><a name="NP_NULL_ON_SOME_PATH_FROM_RETURN_VALUE">NP: Possible null pointer dereference due to return value of called method (NP_NULL_ON_SOME_PATH_FROM_RETURN_VALUE)</a></h3>
<p> A reference value which is null on some exception control path is
dereferenced here. This may lead to a <code>NullPointerException</code>
when the code is executed. The value may be null because it
was return from a method which is known to return possibly-null values.</p>
<h3><a name="PZLA_PREFER_ZERO_LENGTH_ARRAYS">PZLA: Consider returning a zero length array rather than null (PZLA_PREFER_ZERO_LENGTH_ARRAYS)</a></h3>
<p> 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.</p>
<p>On the other hand, using null to indicate
"there is no answer to this question", then it is probably appropriate.
For example, <code>File.listFiles()</code> returns an empty list
if given a directory containing no files, and returns null if the file
is not a directory.</p>
<h3><a name="QF_QUESTIONABLE_FOR_LOOP">QF: Complicated, subtle or wrong increment in for-loop (QF_QUESTIONABLE_FOR_LOOP)</a></h3>
<p>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.
</p>
<h3><a name="RCN_REDUNDANT_COMPARISON_OF_NULL_AND_NONNULL_VALUE">RCN: Redundant comparison of non-null value to null (RCN_REDUNDANT_COMPARISON_OF_NULL_AND_NONNULL_VALUE)</a></h3>
<p> This method contains a reference known to be non-null with another reference
known to be null.</p>
<h3><a name="RCN_REDUNDANT_COMPARISON_TWO_NULL_VALUES">RCN: Redundant comparison of two null values (RCN_REDUNDANT_COMPARISON_TWO_NULL_VALUES)</a></h3>
<p> This method contains a redundant comparison of two references known to
both be definitely null.</p>
<h3><a name="RCN_REDUNDANT_NULLCHECK_OF_NONNULL_VALUE">RCN: Redundant nullcheck of value known to be non-null (RCN_REDUNDANT_NULLCHECK_OF_NONNULL_VALUE)</a></h3>
<p> This method contains a redundant check of a known non-null value against
the constant null.</p>
<h3><a name="RCN_REDUNDANT_NULLCHECK_OF_NULL_VALUE">RCN: Redundant nullcheck of value known to be null (RCN_REDUNDANT_NULLCHECK_OF_NULL_VALUE)</a></h3>
<p> This method contains a redundant check of a known null value against
the constant null.</p>
<h3><a name="REC_CATCH_EXCEPTION">REC: Exception is caught when Exception is not thrown (REC_CATCH_EXCEPTION)</a></h3>
<p>
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.
</p>
<h3><a name="RI_REDUNDANT_INTERFACES">RI: Class implements same interface as superclass (RI_REDUNDANT_INTERFACES)</a></h3>
<p>
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.
</p>
<h3><a name="RV_CHECK_FOR_POSITIVE_INDEXOF">RV: Method checks to see if result of String.indexOf is positive (RV_CHECK_FOR_POSITIVE_INDEXOF)</a></h3>
<p> 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.</p>
<h3><a name="RV_REM_OF_HASHCODE">RV: Remainder of hashCode could be negative (RV_REM_OF_HASHCODE)</a></h3>
<p> This code computes a hashCode, and then computes
the remainder of that value modulo another value. Since the hashCode
can be negative, the result of the remainder operation
can also be negative. </p>
<p> Assuming you want to ensure that the result of your computation is nonnegative,
you may need to change your code.
If you know the divisor is a power of 2,
you can use a bitwise and operator instead (i.e., instead of
using <code>x.hashCode()%n</code>, use <code>x.hashCode()&(n-1)</code>.
This is probably faster than computing the remainder as well.
If you don't know that the divisor is a power of 2, take the absolute
value of the result of the remainder operation (i.e., use
<code>Math.abs(x.hashCode()%n)</code>
</p>
<h3><a name="RV_REM_OF_RANDOM_INT">RV: Remainder of 32-bit signed random integer (RV_REM_OF_RANDOM_INT)</a></h3>
<p> This code generates a random signed integer and then computes
the remainder of that value modulo another value. Since the random
number can be negative, the result of the remainder operation
can also be negative. Be sure this is intended, and strongly
consider using the Random.nextInt(int) method instead.
</p>
<h3><a name="SA_LOCAL_SELF_ASSIGNMENT">SA: Self assignment of local variable (SA_LOCAL_SELF_ASSIGNMENT)</a></h3>
<p> This method contains a self assignment of a local variable; e.g.</p>
<pre>
public void foo() {
int x = 3;
x = x;
}
</pre>
<p>
Such assignments are useless, and may indicate a logic error or typo.
</p>
<h3><a name="SF_SWITCH_FALLTHROUGH">SF: Switch statement found where one case falls through to the next case (SF_SWITCH_FALLTHROUGH)</a></h3>
<p> This method contains a switch statement where one case branch will fall through to the next case.
Usually you need to end this case with a break or return.</p>
<h3><a name="ST_WRITE_TO_STATIC_FROM_INSTANCE_METHOD">ST: Write to static field from instance method (ST_WRITE_TO_STATIC_FROM_INSTANCE_METHOD)</a></h3>
<p> This instance method writes to a static field. This is tricky to get
correct if multiple instances are being manipulated,
and generally bad practice.
</p>
<h3><a name="SE_TRANSIENT_FIELD_OF_NONSERIALIZABLE_CLASS">Se: Transient field of class that isn't Serializable. (SE_TRANSIENT_FIELD_OF_NONSERIALIZABLE_CLASS)</a></h3>
<p> The field is marked as transient, but the class isn't Serializable, so marking it as transient
has absolutely no effect.
This may be leftover marking from a previous version of the code in which the class was transient, or
it may indicate a misunderstanding of how serialization works.
</p>
<h3><a name="UCF_USELESS_CONTROL_FLOW">UCF: Useless control flow (UCF_USELESS_CONTROL_FLOW)</a></h3>
<p> This method contains a useless control flow statement, where
control flow continues onto the same place regardless of whether or not
the branch is taken. For example,
this is caused by having an empty statement
block fot an <code>if</code> statement:</p>
<pre>
if (argv.length == 0) {
// TODO: handle this case
}
</pre>
<h3><a name="UWF_FIELD_NOT_INITIALIZED_IN_CONSTRUCTOR">UwF: Field not initialized in constructor (UWF_FIELD_NOT_INITIALIZED_IN_CONSTRUCTOR)</a></h3>
<p> This field is never initialized within any constructor, and is therefore could be null after
the object is constructed.
This could be 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.
</p>
<h3><a name="XFB_XML_FACTORY_BYPASS">XFB: Method directly allocates a specific implementation of xml interfaces (XFB_XML_FACTORY_BYPASS)</a></h3>
<p>
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
</p>
<ul>
<li>javax.xml.parsers.DocumentBuilderFactory</li>
<li>javax.xml.parsers.SAXParserFactory</li>
<li>javax.xml.transform.TransformerFactory</li>
<li>org.w3c.dom.Document.create<i>XXXX</i></li>
</ul>
<p>for details.</p>
<hr> <p>
<script language="JavaScript" type="text/javascript">
<!---//hide script from old browsers
document.write( "Last updated "+ document.lastModified + "." );
//end hiding contents --->
</script>
<p> Send comments to <a class="sidebar" href="mailto:findbugs@cs.umd.edu">findbugs@cs.umd.edu</a>
<p>
<A href="http://sourceforge.net"><IMG src="http://sourceforge.net/sflogo.php?group_id=96405&type=5" width="210" height="62" border="0" alt="SourceForge.net Logo" /></A>
</td></tr></table>
</body></html>
distrib
>
Mandriva
>
2008.1
>
x86_64
>
media
>
contrib-release
>
by-pkgid
>
95f5ae0ce06780fd3cab0be9375c9914
>
files
>
9
