filelock/src/build/lib/findbugs/doc/allBugDescriptions.html

   1 <html><head><title>FindBugs Bug Descriptions (Unabridged)</title>
   2 <link rel="stylesheet" type="text/css" href="findbugs.css"/>
   3 <link rel="shortcut icon" href="favicon.ico" type="image/x-icon"/>
   4 </head><body>
   5
   6 <table width="100%"><tr>
   7
   8 <td bgcolor="#b9b9fe" valign="top" align="left" width="20%">
   9 <table width="100%" cellspacing="0" border="0">
  10 <tr><td><a class="sidebar" href="index.html"><img src="umdFindbugs.png" alt="FindBugs"></a></td></tr>
  11
  12 <tr><td>&nbsp;</td></tr>
  13
  14 <tr><td><b>Docs and Info</b></td></tr>
  15 <tr><td><font size="-1"><a class="sidebar" href="demo.html">Demo and data</a></font></td></tr>
  16 <tr><td><font size="-1"><a class="sidebar" href="users.html">Users and supporters</a></font></td></tr>
  17 <tr><td><font size="-1"><a class="sidebar" href="http://findbugs.blogspot.com/">FindBugs blog</a></font></td></tr>
  18 <tr><td><font size="-1"><a class="sidebar" href="factSheet.html">Fact sheet</a></font></td></tr>
  19 <tr><td><font size="-1"><a class="sidebar" href="manual/index.html">Manual (en)</a></font></td></tr>
  20 <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>
  21 <tr><td><font size="-1"><a class="sidebar" href="FAQ.html">FAQ</a></font></td></tr>
  22 <tr><td><font size="-1"><a class="sidebar" href="bugDescriptions.html">Bug descriptions</a></font></td></tr>
  23 <tr><td><font size="-1"><a class="sidebar" href="mailingLists.html">Mailing lists</a></font></td></tr>
  24 <tr><td><font size="-1"><a class="sidebar" href="publications.html">Documents and Publications</a></font></td></tr>
  25 <tr><td><font size="-1"><a class="sidebar" href="links.html">Links</a></font></td></tr>
  26
  27 <tr><td>&nbsp;</td></tr>
  28
  29 <tr><td><a class="sidebar" href="downloads.html"><b>Downloads</b></a></td></tr>
  30
  31 <tr><td>&nbsp;</td></tr>
  32
  33 <tr><td><a class="sidebar" href="http://www.cafeshops.com/findbugs"><b>FindBugs Swag</b></a></td></tr>
  34
  35 <tr><td>&nbsp;</td></tr>
  36
  37 <tr><td><b>Development</b></td></tr>
  38 <tr><td><font size="-1"><a class="sidebar" href="reportingBugs.html">Reporting bugs</a></font></td></tr>
  39 <tr><td><font size="-1"><a class="sidebar" href="contributing.html">Contributing</a></font></td></tr>
  40 <tr><td><font size="-1"><a class="sidebar" href="team.html">Dev team</a></font></td></tr>
  41 <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>
  42 <tr><td><font size="-1"><a class="sidebar" href="Changes.html">Change log</a></font></td></tr>
  43 <tr><td><font size="-1"><a class="sidebar" href="http://sourceforge.net/projects/findbugs">SF project page</a></font></td></tr>
  44 <tr><td><font size="-1"><a class="sidebar" href="http://findbugs.cvs.sourceforge.net/findbugs">Browse source</a></font></td></tr>
  45 </table>
  46 </td>
  47 <td align="left" valign="top">
  48 <h1>FindBugs Bug Descriptions (Unabridged)</h1>
  49 <p>This document lists all of the bug patterns reported by the
  50 latest development version of
  51 <a href="http://findbugs.sourceforge.net">FindBugs</a>.&nbsp; Note that this may include
  52 bug patterns not available in any released version of FindBugs,
  53 as well as bug patterns that are not enabled by default.
  54 <h2>Summary</h2>
  55 <table width="100%">
  56 <tr bgcolor="#b9b9fe"><th>Description</th><th>Category</th></tr>
  57 <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>
  58 <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>
  59 <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>
  60 <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>
  61 <tr bgcolor="#eeeeee"><td><a href="#BIT_SIGNED_CHECK">BIT: Check for sign of bitwise operation</a></td><td>Bad practice</td></tr>
  62 <tr bgcolor="#ffffff"><td><a href="#CN_IDIOM">CN: Class implements Cloneable but does not define or use clone method</a></td><td>Bad practice</td></tr>
  63 <tr bgcolor="#eeeeee"><td><a href="#CN_IDIOM_NO_SUPER_CALL">CN: clone method does not call super.clone()</a></td><td>Bad practice</td></tr>
  64 <tr bgcolor="#ffffff"><td><a href="#CO_ABSTRACT_SELF">Co: Abstract class defines covariant compareTo() method</a></td><td>Bad practice</td></tr>
  65 <tr bgcolor="#eeeeee"><td><a href="#CO_SELF_NO_OBJECT">Co: Covariant compareTo() method defined</a></td><td>Bad practice</td></tr>
  66 <tr bgcolor="#ffffff"><td><a href="#DE_MIGHT_DROP">DE: Method might drop exception</a></td><td>Bad practice</td></tr>
  67 <tr bgcolor="#eeeeee"><td><a href="#DE_MIGHT_IGNORE">DE: Method might ignore exception</a></td><td>Bad practice</td></tr>
  68 <tr bgcolor="#ffffff"><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>
  69 <tr bgcolor="#eeeeee"><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>
  70 <tr bgcolor="#ffffff"><td><a href="#DM_EXIT">Dm: Method invokes System.exit(...)</a></td><td>Bad practice</td></tr>
  71 <tr bgcolor="#eeeeee"><td><a href="#DM_RUN_FINALIZERS_ON_EXIT">Dm: Method invokes dangerous method runFinalizersOnExit  </a></td><td>Bad practice</td></tr>
  72 <tr bgcolor="#ffffff"><td><a href="#ES_COMPARING_PARAMETER_STRING_WITH_EQ">ES: Comparison of String parameter using == or !=</a></td><td>Bad practice</td></tr>
  73 <tr bgcolor="#eeeeee"><td><a href="#ES_COMPARING_STRINGS_WITH_EQ">ES: Comparison of String objects using == or !=</a></td><td>Bad practice</td></tr>
  74 <tr bgcolor="#ffffff"><td><a href="#EQ_ABSTRACT_SELF">Eq: Abstract class defines covariant equals() method</a></td><td>Bad practice</td></tr>
  75 <tr bgcolor="#eeeeee"><td><a href="#EQ_COMPARETO_USE_OBJECT_EQUALS">Eq: Class defines compareTo(...) and uses Object.equals()</a></td><td>Bad practice</td></tr>
  76 <tr bgcolor="#ffffff"><td><a href="#EQ_SELF_NO_OBJECT">Eq: Covariant equals() method defined</a></td><td>Bad practice</td></tr>
  77 <tr bgcolor="#eeeeee"><td><a href="#EQ_SELF_USE_OBJECT">Eq: Covariant equals() method defined, Object.equals(Object) inherited</a></td><td>Bad practice</td></tr>
  78 <tr bgcolor="#ffffff"><td><a href="#FI_EMPTY">FI: Empty finalizer should be deleted</a></td><td>Bad practice</td></tr>
  79 <tr bgcolor="#eeeeee"><td><a href="#FI_EXPLICIT_INVOCATION">FI: Explicit invocation of finalizer</a></td><td>Bad practice</td></tr>
  80 <tr bgcolor="#ffffff"><td><a href="#FI_FINALIZER_NULLS_FIELDS">FI: Finalizer nulls fields</a></td><td>Bad practice</td></tr>
  81 <tr bgcolor="#eeeeee"><td><a href="#FI_FINALIZER_ONLY_NULLS_FIELDS">FI: Finalizer only nulls fields</a></td><td>Bad practice</td></tr>
  82 <tr bgcolor="#ffffff"><td><a href="#FI_MISSING_SUPER_CALL">FI: Finalizer does not call superclass finalizer</a></td><td>Bad practice</td></tr>
  83 <tr bgcolor="#eeeeee"><td><a href="#FI_NULLIFY_SUPER">FI: Finalizer nullifies superclass finalizer</a></td><td>Bad practice</td></tr>
  84 <tr bgcolor="#ffffff"><td><a href="#FI_USELESS">FI: Finalizer does nothing but call superclass finalizer</a></td><td>Bad practice</td></tr>
  85 <tr bgcolor="#eeeeee"><td><a href="#HE_EQUALS_NO_HASHCODE">HE: Class defines equals() but not hashCode()</a></td><td>Bad practice</td></tr>
  86 <tr bgcolor="#ffffff"><td><a href="#HE_EQUALS_USE_HASHCODE">HE: Class defines equals() and uses Object.hashCode()</a></td><td>Bad practice</td></tr>
  87 <tr bgcolor="#eeeeee"><td><a href="#HE_HASHCODE_NO_EQUALS">HE: Class defines hashCode() but not equals()</a></td><td>Bad practice</td></tr>
  88 <tr bgcolor="#ffffff"><td><a href="#HE_HASHCODE_USE_OBJECT_EQUALS">HE: Class defines hashCode() and uses Object.equals()</a></td><td>Bad practice</td></tr>
  89 <tr bgcolor="#eeeeee"><td><a href="#HE_INHERITS_EQUALS_USE_HASHCODE">HE: Class inherits equals() and uses Object.hashCode()</a></td><td>Bad practice</td></tr>
  90 <tr bgcolor="#ffffff"><td><a href="#IC_SUPERCLASS_USES_SUBCLASS_DURING_INITIALIZATION">IC: Superclass uses subclass during initialization</a></td><td>Bad practice</td></tr>
  91 <tr bgcolor="#eeeeee"><td><a href="#IMSE_DONT_CATCH_IMSE">IMSE: Dubious catching of IllegalMonitorStateException</a></td><td>Bad practice</td></tr>
  92 <tr bgcolor="#ffffff"><td><a href="#ISC_INSTANTIATE_STATIC_CLASS">ISC: Needless instantiation of class that only supplies static methods</a></td><td>Bad practice</td></tr>
  93 <tr bgcolor="#eeeeee"><td><a href="#IT_NO_SUCH_ELEMENT">It: Iterator next() method can't throw NoSuchElement exception</a></td><td>Bad practice</td></tr>
  94 <tr bgcolor="#ffffff"><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>
  95 <tr bgcolor="#eeeeee"><td><a href="#NP_CLONE_COULD_RETURN_NULL">NP: Clone method may return null</a></td><td>Bad practice</td></tr>
  96 <tr bgcolor="#ffffff"><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>
  97 <tr bgcolor="#eeeeee"><td><a href="#NP_TOSTRING_COULD_RETURN_NULL">NP: toString method may return null</a></td><td>Bad practice</td></tr>
  98 <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>
  99 <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>
 100 <tr bgcolor="#ffffff"><td><a href="#NM_CONFUSING">Nm: Confusing method names</a></td><td>Bad practice</td></tr>
 101 <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>
 102 <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>
 103 <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>
 104 <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>
 105 <tr bgcolor="#eeeeee"><td><a href="#NM_SAME_SIMPLE_NAME_AS_INTERFACE">Nm: Class names shouldn't shadow simple name of implemented interface</a></td><td>Bad practice</td></tr>
 106 <tr bgcolor="#ffffff"><td><a href="#NM_SAME_SIMPLE_NAME_AS_SUPERCLASS">Nm: Class names shouldn't shadow simple name of superclass</a></td><td>Bad practice</td></tr>
 107 <tr bgcolor="#eeeeee"><td><a href="#NM_VERY_CONFUSING_INTENTIONAL">Nm: Very confusing method names</a></td><td>Bad practice</td></tr>
 108 <tr bgcolor="#ffffff"><td><a href="#NM_WRONG_PACKAGE_INTENTIONAL">Nm: Method doesn't override method in superclass due to wrong package for parameter</a></td><td>Bad practice</td></tr>
 109 <tr bgcolor="#eeeeee"><td><a href="#ODR_OPEN_DATABASE_RESOURCE">ODR: Method may fail to close database resource</a></td><td>Bad practice</td></tr>
 110 <tr bgcolor="#ffffff"><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>
 111 <tr bgcolor="#eeeeee"><td><a href="#OS_OPEN_STREAM">OS: Method may fail to close stream</a></td><td>Bad practice</td></tr>
 112 <tr bgcolor="#ffffff"><td><a href="#OS_OPEN_STREAM_EXCEPTION_PATH">OS: Method may fail to close stream on exception</a></td><td>Bad practice</td></tr>
 113 <tr bgcolor="#eeeeee"><td><a href="#RC_REF_COMPARISON">RC: Suspicious reference comparison</a></td><td>Bad practice</td></tr>
 114 <tr bgcolor="#ffffff"><td><a href="#RR_NOT_CHECKED">RR: Method ignores results of InputStream.read()</a></td><td>Bad practice</td></tr>
 115 <tr bgcolor="#eeeeee"><td><a href="#SR_NOT_CHECKED">RR: Method ignores results of InputStream.skip()</a></td><td>Bad practice</td></tr>
 116 <tr bgcolor="#ffffff"><td><a href="#RV_RETURN_VALUE_IGNORED_BAD_PRACTICE">RV: Method ignores return value</a></td><td>Bad practice</td></tr>
 117 <tr bgcolor="#eeeeee"><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>
 118 <tr bgcolor="#ffffff"><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>
 119 <tr bgcolor="#eeeeee"><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>
 120 <tr bgcolor="#ffffff"><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>
 121 <tr bgcolor="#eeeeee"><td><a href="#SE_BAD_FIELD">Se: Non-transient non-serializable instance field in serializable class</a></td><td>Bad practice</td></tr>
 122 <tr bgcolor="#ffffff"><td><a href="#SE_BAD_FIELD_INNER_CLASS">Se: Non-serializable class has a serializable inner class</a></td><td>Bad practice</td></tr>
 123 <tr bgcolor="#eeeeee"><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>
 124 <tr bgcolor="#ffffff"><td><a href="#SE_COMPARATOR_SHOULD_BE_SERIALIZABLE">Se: Comparator doesn't implement Serializable</a></td><td>Bad practice</td></tr>
 125 <tr bgcolor="#eeeeee"><td><a href="#SE_INNER_CLASS">Se: Serializable inner class</a></td><td>Bad practice</td></tr>
 126 <tr bgcolor="#ffffff"><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>
 127 <tr bgcolor="#eeeeee"><td><a href="#SE_NONFINAL_SERIALVERSIONID">Se: serialVersionUID isn't final</a></td><td>Bad practice</td></tr>
 128 <tr bgcolor="#ffffff"><td><a href="#SE_NONLONG_SERIALVERSIONID">Se: serialVersionUID isn't long</a></td><td>Bad practice</td></tr>
 129 <tr bgcolor="#eeeeee"><td><a href="#SE_NONSTATIC_SERIALVERSIONID">Se: serialVersionUID isn't static</a></td><td>Bad practice</td></tr>
 130 <tr bgcolor="#ffffff"><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>
 131 <tr bgcolor="#eeeeee"><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>
 132 <tr bgcolor="#ffffff"><td><a href="#SE_READ_RESOLVE_MUST_RETURN_OBJECT">Se: The readResolve method must be declared with a return type
 133 of Object. </a></td><td>Bad practice</td></tr>
 134 <tr bgcolor="#eeeeee"><td><a href="#SE_TRANSIENT_FIELD_NOT_RESTORED">Se: Transient field that isn't set by deserialization. </a></td><td>Bad practice</td></tr>
 135 <tr bgcolor="#ffffff"><td><a href="#SE_NO_SERIALVERSIONID">SnVI: Class is Serializable, but doesn't define serialVersionUID</a></td><td>Bad practice</td></tr>
 136 <tr bgcolor="#eeeeee"><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>
 137 <tr bgcolor="#ffffff"><td><a href="#BC_IMPOSSIBLE_CAST">BC: Impossible cast</a></td><td>Correctness</td></tr>
 138 <tr bgcolor="#eeeeee"><td><a href="#BC_IMPOSSIBLE_INSTANCEOF">BC: instanceof will always return false</a></td><td>Correctness</td></tr>
 139 <tr bgcolor="#ffffff"><td><a href="#BIT_AND">BIT: Incompatible bit masks</a></td><td>Correctness</td></tr>
 140 <tr bgcolor="#eeeeee"><td><a href="#BIT_AND_ZZ">BIT: Check to see if ((...) & 0) == 0</a></td><td>Correctness</td></tr>
 141 <tr bgcolor="#ffffff"><td><a href="#BIT_IOR">BIT: Incompatible bit masks</a></td><td>Correctness</td></tr>
 142 <tr bgcolor="#eeeeee"><td><a href="#BIT_IOR_OF_SIGNED_BYTE">BIT: Bitwise OR of signed byte value</a></td><td>Correctness</td></tr>
 143 <tr bgcolor="#ffffff"><td><a href="#BIT_SIGNED_CHECK_HIGH_BIT">BIT: Check for sign of bitwise operation</a></td><td>Correctness</td></tr>
 144 <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>
 145 <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>
 146 <tr bgcolor="#eeeeee"><td><a href="#DLS_DEAD_STORE_OF_CLASS_LITERAL">DLS: Dead store of class literal</a></td><td>Correctness</td></tr>
 147 <tr bgcolor="#ffffff"><td><a href="#DLS_OVERWRITTEN_INCREMENT">DLS: Overwritten increment</a></td><td>Correctness</td></tr>
 148 <tr bgcolor="#eeeeee"><td><a href="#DMI_BAD_MONTH">DMI: Bad constant value for month</a></td><td>Correctness</td></tr>
 149 <tr bgcolor="#ffffff"><td><a href="#DMI_CALLING_NEXT_FROM_HASNEXT">DMI: hasNext method invokes next</a></td><td>Correctness</td></tr>
 150 <tr bgcolor="#eeeeee"><td><a href="#DMI_INVOKING_TOSTRING_ON_ARRAY">DMI: Invocation of toString on an array</a></td><td>Correctness</td></tr>
 151 <tr bgcolor="#ffffff"><td><a href="#DMI_LONG_BITS_TO_DOUBLE_INVOKED_ON_INT">DMI: Double.longBitsToDouble invoked on an int</a></td><td>Correctness</td></tr>
 152 <tr bgcolor="#eeeeee"><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>
 153 <tr bgcolor="#ffffff"><td><a href="#EC_ARRAY_AND_NONARRAY">EC: equals() used to compare array and nonarray</a></td><td>Correctness</td></tr>
 154 <tr bgcolor="#eeeeee"><td><a href="#EC_BAD_ARRAY_COMPARE">EC: Invocation of equals() on an array, which is equivalent to ==</a></td><td>Correctness</td></tr>
 155 <tr bgcolor="#ffffff"><td><a href="#EC_NULL_ARG">EC: Call to equals() with null argument</a></td><td>Correctness</td></tr>
 156 <tr bgcolor="#eeeeee"><td><a href="#EC_UNRELATED_CLASS_AND_INTERFACE">EC: Call to equals() comparing unrelated class and interface</a></td><td>Correctness</td></tr>
 157 <tr bgcolor="#ffffff"><td><a href="#EC_UNRELATED_INTERFACES">EC: Call to equals() comparing different interface types</a></td><td>Correctness</td></tr>
 158 <tr bgcolor="#eeeeee"><td><a href="#EC_UNRELATED_TYPES">EC: Call to equals() comparing different types</a></td><td>Correctness</td></tr>
 159 <tr bgcolor="#ffffff"><td><a href="#EC_UNRELATED_TYPES_USING_POINTER_EQUALITY">EC: Using pointer equality  to compare  different types</a></td><td>Correctness</td></tr>
 160 <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>
 161 <tr bgcolor="#ffffff"><td><a href="#EQ_OVERRIDING_EQUALS_NOT_SYMMETRIC">Eq: equals method overrides equals in superclass and may not be symmetric</a></td><td>Correctness</td></tr>
 162 <tr bgcolor="#eeeeee"><td><a href="#FE_TEST_IF_EQUAL_TO_NOT_A_NUMBER">FE: Doomed test for equality to NaN</a></td><td>Correctness</td></tr>
 163 <tr bgcolor="#ffffff"><td><a href="#GC_UNRELATED_TYPES">GC: No relationship between generic parameter and method argument</a></td><td>Correctness</td></tr>
 164 <tr bgcolor="#eeeeee"><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>
 165 <tr bgcolor="#ffffff"><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>
 166 <tr bgcolor="#eeeeee"><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>
 167 <tr bgcolor="#ffffff"><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>
 168 <tr bgcolor="#eeeeee"><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>
 169 <tr bgcolor="#ffffff"><td><a href="#IJU_BAD_SUITE_METHOD">IJU: TestCase declares a bad suite method </a></td><td>Correctness</td></tr>
 170 <tr bgcolor="#eeeeee"><td><a href="#IJU_NO_TESTS">IJU: TestCase has no tests</a></td><td>Correctness</td></tr>
 171 <tr bgcolor="#ffffff"><td><a href="#IJU_SETUP_NO_SUPER">IJU: TestCase implements setUp but doesn't call super.setUp()</a></td><td>Correctness</td></tr>
 172 <tr bgcolor="#eeeeee"><td><a href="#IJU_SUITE_NOT_STATIC">IJU: TestCase implements a non-static suite method </a></td><td>Correctness</td></tr>
 173 <tr bgcolor="#ffffff"><td><a href="#IJU_TEARDOWN_NO_SUPER">IJU: TestCase implements tearDown but doesn't call super.tearDown()</a></td><td>Correctness</td></tr>
 174 <tr bgcolor="#eeeeee"><td><a href="#IL_CONTAINER_ADDED_TO_ITSELF">IL: A container is added to itself</a></td><td>Correctness</td></tr>
 175 <tr bgcolor="#ffffff"><td><a href="#IL_INFINITE_LOOP">IL: An apparent infinite loop</a></td><td>Correctness</td></tr>
 176 <tr bgcolor="#eeeeee"><td><a href="#IL_INFINITE_RECURSIVE_LOOP">IL: An apparent infinite recursive loop</a></td><td>Correctness</td></tr>
 177 <tr bgcolor="#ffffff"><td><a href="#IM_MULTIPLYING_RESULT_OF_IREM">IM: Integer multiply of result of integer remainder</a></td><td>Correctness</td></tr>
 178 <tr bgcolor="#eeeeee"><td><a href="#INT_BAD_COMPARISON_WITH_NONNEGATIVE_VALUE">INT: Bad comparison of nonnegative value with negative constant</a></td><td>Correctness</td></tr>
 179 <tr bgcolor="#ffffff"><td><a href="#INT_BAD_COMPARISON_WITH_SIGNED_BYTE">INT: Bad comparison of signed byte</a></td><td>Correctness</td></tr>
 180 <tr bgcolor="#eeeeee"><td><a href="#INT_BAD_REM_BY_1">INT: Integer remainder modulo 1</a></td><td>Correctness</td></tr>
 181 <tr bgcolor="#ffffff"><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>
 182 <tr bgcolor="#eeeeee"><td><a href="#JCIP_FIELD_ISNT_FINAL_IN_IMMUTABLE_CLASS">JCIP: Fields of immutable classes should be final</a></td><td>Correctness</td></tr>
 183 <tr bgcolor="#ffffff"><td><a href="#MF_CLASS_MASKS_FIELD">MF: Class defines field that masks a superclass field</a></td><td>Correctness</td></tr>
 184 <tr bgcolor="#eeeeee"><td><a href="#MF_METHOD_MASKS_FIELD">MF: Method defines a variable that obscures a field</a></td><td>Correctness</td></tr>
 185 <tr bgcolor="#ffffff"><td><a href="#NP_ALWAYS_NULL">NP: Null pointer dereference</a></td><td>Correctness</td></tr>
 186 <tr bgcolor="#eeeeee"><td><a href="#NP_ALWAYS_NULL_EXCEPTION">NP: Null pointer dereference in method on exception path</a></td><td>Correctness</td></tr>
 187 <tr bgcolor="#ffffff"><td><a href="#NP_ARGUMENT_MIGHT_BE_NULL">NP: Method does not check for null argument</a></td><td>Correctness</td></tr>
 188 <tr bgcolor="#eeeeee"><td><a href="#NP_GUARANTEED_DEREF">NP: Null value is guaranteed to be dereferenced</a></td><td>Correctness</td></tr>
 189 <tr bgcolor="#ffffff"><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>
 190 <tr bgcolor="#eeeeee"><td><a href="#NP_NONNULL_PARAM_VIOLATION">NP: Method call passes null to a nonnull parameter </a></td><td>Correctness</td></tr>
 191 <tr bgcolor="#ffffff"><td><a href="#NP_NONNULL_RETURN_VIOLATION">NP: Method may return null, but is declared @NonNull</a></td><td>Correctness</td></tr>
 192 <tr bgcolor="#eeeeee"><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>
 193 <tr bgcolor="#ffffff"><td><a href="#NP_NULL_ON_SOME_PATH">NP: Possible null pointer dereference</a></td><td>Correctness</td></tr>
 194 <tr bgcolor="#eeeeee"><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>
 195 <tr bgcolor="#ffffff"><td><a href="#NP_NULL_PARAM_DEREF">NP: Method call passes null for unconditionally dereferenced parameter</a></td><td>Correctness</td></tr>
 196 <tr bgcolor="#eeeeee"><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>
 197 <tr bgcolor="#ffffff"><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>
 198 <tr bgcolor="#eeeeee"><td><a href="#NP_STORE_INTO_NONNULL_FIELD">NP: Store of null value into field annotated NonNull</a></td><td>Correctness</td></tr>
 199 <tr bgcolor="#ffffff"><td><a href="#NP_UNWRITTEN_FIELD">NP: Read of unwritten field</a></td><td>Correctness</td></tr>
 200 <tr bgcolor="#eeeeee"><td><a href="#NM_BAD_EQUAL">Nm: Class defines equal(); should it be equals()?</a></td><td>Correctness</td></tr>
 201 <tr bgcolor="#ffffff"><td><a href="#NM_LCASE_HASHCODE">Nm: Class defines hashcode(); should it be hashCode()?</a></td><td>Correctness</td></tr>
 202 <tr bgcolor="#eeeeee"><td><a href="#NM_LCASE_TOSTRING">Nm: Class defines tostring(); should it be toString()?</a></td><td>Correctness</td></tr>
 203 <tr bgcolor="#ffffff"><td><a href="#NM_METHOD_CONSTRUCTOR_CONFUSION">Nm: Apparent method/constructor confusion</a></td><td>Correctness</td></tr>
 204 <tr bgcolor="#eeeeee"><td><a href="#NM_VERY_CONFUSING">Nm: Very confusing method names</a></td><td>Correctness</td></tr>
 205 <tr bgcolor="#ffffff"><td><a href="#NM_WRONG_PACKAGE">Nm: Method doesn't override method in superclass due to wrong package for parameter</a></td><td>Correctness</td></tr>
 206 <tr bgcolor="#eeeeee"><td><a href="#QBA_QUESTIONABLE_BOOLEAN_ASSIGNMENT">QBA: Method assigns boolean literal in boolean expression</a></td><td>Correctness</td></tr>
 207 <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>
 208 <tr bgcolor="#eeeeee"><td><a href="#RE_BAD_SYNTAX_FOR_REGULAR_EXPRESSION">RE: Invalid syntax for regular expression</a></td><td>Correctness</td></tr>
 209 <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>
 210 <tr bgcolor="#eeeeee"><td><a href="#RE_POSSIBLE_UNINTENDED_PATTERN">RE: "." used for regular expression</a></td><td>Correctness</td></tr>
 211 <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>
 212 <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>
 213 <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>
 214 <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>
 215 <tr bgcolor="#ffffff"><td><a href="#RV_EXCEPTION_NOT_THROWN">RV: Exception created and dropped rather than thrown</a></td><td>Correctness</td></tr>
 216 <tr bgcolor="#eeeeee"><td><a href="#RV_RETURN_VALUE_IGNORED">RV: Method ignores return value</a></td><td>Correctness</td></tr>
 217 <tr bgcolor="#ffffff"><td><a href="#SA_FIELD_DOUBLE_ASSIGNMENT">SA: Double assignment of field</a></td><td>Correctness</td></tr>
 218 <tr bgcolor="#eeeeee"><td><a href="#SA_FIELD_SELF_ASSIGNMENT">SA: Self assignment of field</a></td><td>Correctness</td></tr>
 219 <tr bgcolor="#ffffff"><td><a href="#SA_FIELD_SELF_COMPARISON">SA: Self comparison of field with itself</a></td><td>Correctness</td></tr>
 220 <tr bgcolor="#eeeeee"><td><a href="#SA_FIELD_SELF_COMPUTATION">SA: Nonsensical self computation involving a field (e.g., x & x)</a></td><td>Correctness</td></tr>
 221 <tr bgcolor="#ffffff"><td><a href="#SA_LOCAL_DOUBLE_ASSIGNMENT">SA: Double assignment of local variable </a></td><td>Correctness</td></tr>
 222 <tr bgcolor="#eeeeee"><td><a href="#SA_LOCAL_SELF_COMPARISON">SA: Self comparison of value with itself</a></td><td>Correctness</td></tr>
 223 <tr bgcolor="#ffffff"><td><a href="#SA_LOCAL_SELF_COMPUTATION">SA: Nonsensical self computation involving a variable (e.g., x & x)</a></td><td>Correctness</td></tr>
 224 <tr bgcolor="#eeeeee"><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>
 225 <tr bgcolor="#ffffff"><td><a href="#SIO_SUPERFLUOUS_INSTANCEOF">SIO: Unnecessary type check done using instanceof operator</a></td><td>Correctness</td></tr>
 226 <tr bgcolor="#eeeeee"><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>
 227 <tr bgcolor="#ffffff"><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>
 228 <tr bgcolor="#eeeeee"><td><a href="#STI_INTERRUPTED_ON_CURRENTTHREAD">STI: Unneeded use of currentThread() call, to call interrupted() </a></td><td>Correctness</td></tr>
 229 <tr bgcolor="#ffffff"><td><a href="#STI_INTERRUPTED_ON_UNKNOWNTHREAD">STI: Static Thread.interrupted() method invoked on thread instance</a></td><td>Correctness</td></tr>
 230 <tr bgcolor="#eeeeee"><td><a href="#TQ_ALWAYS_VALUE_USED_WHERE_NEVER_REQUIRED">TQ: Value annotated as carrying a type qualifier used where a value that must not carry that qualifier is required</a></td><td>Correctness</td></tr>
 231 <tr bgcolor="#ffffff"><td><a href="#TQ_MAYBE_SOURCE_VALUE_REACHES_ALWAYS_SINK">TQ: Value that might not carry a type qualifier reaches a use requiring that type qualifier</a></td><td>Correctness</td></tr>
 232 <tr bgcolor="#eeeeee"><td><a href="#TQ_MAYBE_SOURCE_VALUE_REACHES_NEVER_SINK">TQ: Unknown value reaches a use which forbids values carrying type qualifier annotation</a></td><td>Correctness</td></tr>
 233 <tr bgcolor="#ffffff"><td><a href="#TQ_NEVER_VALUE_USED_WHERE_ALWAYS_REQUIRED">TQ: Value annotated as never carrying a type qualifier used where value carrying that qualifier is required</a></td><td>Correctness</td></tr>
 234 <tr bgcolor="#eeeeee"><td><a href="#UCF_USELESS_CONTROL_FLOW_NEXT_LINE">UCF: Useless control flow to next line</a></td><td>Correctness</td></tr>
 235 <tr bgcolor="#ffffff"><td><a href="#UMAC_UNCALLABLE_METHOD_OF_ANONYMOUS_CLASS">UMAC: Uncallable method defined in anonymous class</a></td><td>Correctness</td></tr>
 236 <tr bgcolor="#eeeeee"><td><a href="#UR_UNINIT_READ">UR: Uninitialized read of field in constructor</a></td><td>Correctness</td></tr>
 237 <tr bgcolor="#ffffff"><td><a href="#UWF_NULL_FIELD">UwF: Field only ever set to null</a></td><td>Correctness</td></tr>
 238 <tr bgcolor="#eeeeee"><td><a href="#UWF_UNWRITTEN_FIELD">UwF: Unwritten field</a></td><td>Correctness</td></tr>
 239 <tr bgcolor="#ffffff"><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>
 240 <tr bgcolor="#eeeeee"><td><a href="#DM_CONVERT_CASE">Dm: Consider using Locale parameterized version of invoked method</a></td><td>Internationalization</td></tr>
 241 <tr bgcolor="#ffffff"><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>
 242 <tr bgcolor="#eeeeee"><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>
 243 <tr bgcolor="#ffffff"><td><a href="#FI_PUBLIC_SHOULD_BE_PROTECTED">FI: Finalizer should be protected, not public</a></td><td>Malicious code vulnerability</td></tr>
 244 <tr bgcolor="#eeeeee"><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>
 245 <tr bgcolor="#ffffff"><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>
 246 <tr bgcolor="#eeeeee"><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>
 247 <tr bgcolor="#ffffff"><td><a href="#MS_FINAL_PKGPROTECT">MS: Field should be both final and package protected</a></td><td>Malicious code vulnerability</td></tr>
 248 <tr bgcolor="#eeeeee"><td><a href="#MS_MUTABLE_ARRAY">MS: Field is a mutable array</a></td><td>Malicious code vulnerability</td></tr>
 249 <tr bgcolor="#ffffff"><td><a href="#MS_MUTABLE_HASHTABLE">MS: Field is a mutable Hashtable</a></td><td>Malicious code vulnerability</td></tr>
 250 <tr bgcolor="#eeeeee"><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>
 251 <tr bgcolor="#ffffff"><td><a href="#MS_PKGPROTECT">MS: Field should be package protected</a></td><td>Malicious code vulnerability</td></tr>
 252 <tr bgcolor="#eeeeee"><td><a href="#MS_SHOULD_BE_FINAL">MS: Field isn't final but should be</a></td><td>Malicious code vulnerability</td></tr>
 253 <tr bgcolor="#ffffff"><td><a href="#DC_DOUBLECHECK">DC: Possible double check of field</a></td><td>Multithreaded correctness</td></tr>
 254 <tr bgcolor="#eeeeee"><td><a href="#DL_SYNCHRONIZATION_ON_SHARED_CONSTANT">DL: Synchronization on shared constant could lead to deadlock</a></td><td>Multithreaded correctness</td></tr>
 255 <tr bgcolor="#ffffff"><td><a href="#DM_MONITOR_WAIT_ON_CONDITION">Dm: Monitor wait() called on Condition</a></td><td>Multithreaded correctness</td></tr>
 256 <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>
 257 <tr bgcolor="#ffffff"><td><a href="#ESync_EMPTY_SYNC">ESync: Empty synchronized block</a></td><td>Multithreaded correctness</td></tr>
 258 <tr bgcolor="#eeeeee"><td><a href="#IS2_INCONSISTENT_SYNC">IS: Inconsistent synchronization</a></td><td>Multithreaded correctness</td></tr>
 259 <tr bgcolor="#ffffff"><td><a href="#IS_FIELD_NOT_GUARDED">IS: Field not guarded against concurrent access</a></td><td>Multithreaded correctness</td></tr>
 260 <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>
 261 <tr bgcolor="#ffffff"><td><a href="#LI_LAZY_INIT_STATIC">LI: Incorrect lazy initialization of static field</a></td><td>Multithreaded correctness</td></tr>
 262 <tr bgcolor="#eeeeee"><td><a href="#LI_LAZY_INIT_UPDATE_STATIC">LI: Incorrect lazy initialization and update of static field</a></td><td>Multithreaded correctness</td></tr>
 263 <tr bgcolor="#ffffff"><td><a href="#ML_SYNC_ON_UPDATED_FIELD">ML: Method synchronizes on an updated field</a></td><td>Multithreaded correctness</td></tr>
 264 <tr bgcolor="#eeeeee"><td><a href="#MWN_MISMATCHED_NOTIFY">MWN: Mismatched notify()</a></td><td>Multithreaded correctness</td></tr>
 265 <tr bgcolor="#ffffff"><td><a href="#MWN_MISMATCHED_WAIT">MWN: Mismatched wait()</a></td><td>Multithreaded correctness</td></tr>
 266 <tr bgcolor="#eeeeee"><td><a href="#NN_NAKED_NOTIFY">NN: Naked notify</a></td><td>Multithreaded correctness</td></tr>
 267 <tr bgcolor="#ffffff"><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>
 268 <tr bgcolor="#eeeeee"><td><a href="#NO_NOTIFY_NOT_NOTIFYALL">No: Using notify() rather than notifyAll()</a></td><td>Multithreaded correctness</td></tr>
 269 <tr bgcolor="#ffffff"><td><a href="#RS_READOBJECT_SYNC">RS: Class's readObject() method is synchronized</a></td><td>Multithreaded correctness</td></tr>
 270 <tr bgcolor="#eeeeee"><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>
 271 <tr bgcolor="#ffffff"><td><a href="#SC_START_IN_CTOR">SC: Constructor invokes Thread.start()</a></td><td>Multithreaded correctness</td></tr>
 272 <tr bgcolor="#eeeeee"><td><a href="#SP_SPIN_ON_FIELD">SP: Method spins on field</a></td><td>Multithreaded correctness</td></tr>
 273 <tr bgcolor="#ffffff"><td><a href="#STCAL_INVOKE_ON_STATIC_CALENDAR_INSTANCE">STCAL: Call to static Calendar</a></td><td>Multithreaded correctness</td></tr>
 274 <tr bgcolor="#eeeeee"><td><a href="#STCAL_INVOKE_ON_STATIC_DATE_FORMAT_INSTANCE">STCAL: Call to static DateFormat</a></td><td>Multithreaded correctness</td></tr>
 275 <tr bgcolor="#ffffff"><td><a href="#STCAL_STATIC_CALENDAR_INSTANCE">STCAL: Static Calendar</a></td><td>Multithreaded correctness</td></tr>
 276 <tr bgcolor="#eeeeee"><td><a href="#STCAL_STATIC_SIMPLE_DATE_FORMAT_INSTANCE">STCAL: Static DateFormat</a></td><td>Multithreaded correctness</td></tr>
 277 <tr bgcolor="#ffffff"><td><a href="#SWL_SLEEP_WITH_LOCK_HELD">SWL: Method calls Thread.sleep() with a lock held</a></td><td>Multithreaded correctness</td></tr>
 278 <tr bgcolor="#eeeeee"><td><a href="#TLW_TWO_LOCK_WAIT">TLW: Wait with two locks held</a></td><td>Multithreaded correctness</td></tr>
 279 <tr bgcolor="#ffffff"><td><a href="#UG_SYNC_SET_UNSYNC_GET">UG: Unsynchronized get method, synchronized set method</a></td><td>Multithreaded correctness</td></tr>
 280 <tr bgcolor="#eeeeee"><td><a href="#UL_UNRELEASED_LOCK">UL: Method does not release lock on all paths</a></td><td>Multithreaded correctness</td></tr>
 281 <tr bgcolor="#ffffff"><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>
 282 <tr bgcolor="#eeeeee"><td><a href="#UW_UNCOND_WAIT">UW: Unconditional wait</a></td><td>Multithreaded correctness</td></tr>
 283 <tr bgcolor="#ffffff"><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>
 284 <tr bgcolor="#eeeeee"><td><a href="#WS_WRITEOBJECT_SYNC">WS: Class's writeObject() method is synchronized but nothing else is</a></td><td>Multithreaded correctness</td></tr>
 285 <tr bgcolor="#ffffff"><td><a href="#WA_AWAIT_NOT_IN_LOOP">Wa: Condition.await() not in loop </a></td><td>Multithreaded correctness</td></tr>
 286 <tr bgcolor="#eeeeee"><td><a href="#WA_NOT_IN_LOOP">Wa: Wait not in loop </a></td><td>Multithreaded correctness</td></tr>
 287 <tr bgcolor="#ffffff"><td><a href="#BX_BOXING_IMMEDIATELY_UNBOXED">Bx: Primitive value is boxed and then immediately unboxed</a></td><td>Performance</td></tr>
 288 <tr bgcolor="#eeeeee"><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>
 289 <tr bgcolor="#ffffff"><td><a href="#DM_BOXED_PRIMITIVE_TOSTRING">Bx: Method allocates a boxed primitive just to call toString</a></td><td>Performance</td></tr>
 290 <tr bgcolor="#eeeeee"><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>
 291 <tr bgcolor="#ffffff"><td><a href="#DM_NUMBER_CTOR">Bx: Method invokes inefficient Number constructor; use static valueOf instead</a></td><td>Performance</td></tr>
 292 <tr bgcolor="#eeeeee"><td><a href="#DMI_BLOCKING_METHODS_ON_URL">Dm: The equals and hashCode methods of URL are blocking</a></td><td>Performance</td></tr>
 293 <tr bgcolor="#ffffff"><td><a href="#DMI_COLLECTION_OF_URLS">Dm: Maps and sets of URLs can be performance hogs</a></td><td>Performance</td></tr>
 294 <tr bgcolor="#eeeeee"><td><a href="#DM_BOOLEAN_CTOR">Dm: Method invokes inefficient Boolean constructor; use Boolean.valueOf(...) instead</a></td><td>Performance</td></tr>
 295 <tr bgcolor="#ffffff"><td><a href="#DM_GC">Dm: Explicit garbage collection; extremely dubious except in benchmarking code</a></td><td>Performance</td></tr>
 296 <tr bgcolor="#eeeeee"><td><a href="#DM_NEW_FOR_GETCLASS">Dm: Method allocates an object, only to get the class object</a></td><td>Performance</td></tr>
 297 <tr bgcolor="#ffffff"><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>
 298 <tr bgcolor="#eeeeee"><td><a href="#DM_STRING_CTOR">Dm: Method invokes inefficient new String(String) constructor</a></td><td>Performance</td></tr>
 299 <tr bgcolor="#ffffff"><td><a href="#DM_STRING_EMPTY_EQUALS">Dm: Method invokes inefficient String.equals(""); use String.length() == 0 instead</a></td><td>Performance</td></tr>
 300 <tr bgcolor="#eeeeee"><td><a href="#DM_STRING_TOSTRING">Dm: Method invokes toString() method on a String</a></td><td>Performance</td></tr>
 301 <tr bgcolor="#ffffff"><td><a href="#DM_STRING_VOID_CTOR">Dm: Method invokes inefficient new String() constructor</a></td><td>Performance</td></tr>
 302 <tr bgcolor="#eeeeee"><td><a href="#HSC_HUGE_SHARED_STRING_CONSTANT">HSC: Huge string constants is duplicated across multiple class files</a></td><td>Performance</td></tr>
 303 <tr bgcolor="#ffffff"><td><a href="#ITA_INEFFICIENT_TO_ARRAY">ITA: Method uses toArray() with zero-length array argument</a></td><td>Performance</td></tr>
 304 <tr bgcolor="#eeeeee"><td><a href="#SBSC_USE_STRINGBUFFER_CONCATENATION">SBSC: Method concatenates strings using + in a loop</a></td><td>Performance</td></tr>
 305 <tr bgcolor="#ffffff"><td><a href="#SIC_INNER_SHOULD_BE_STATIC">SIC: Should be a static inner class</a></td><td>Performance</td></tr>
 306 <tr bgcolor="#eeeeee"><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>
 307 <tr bgcolor="#ffffff"><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>
 308 <tr bgcolor="#eeeeee"><td><a href="#SS_SHOULD_BE_STATIC">SS: Unread field: should this field be static?</a></td><td>Performance</td></tr>
 309 <tr bgcolor="#ffffff"><td><a href="#UM_UNNECESSARY_MATH">UM: Method calls static Math class method on a constant value</a></td><td>Performance</td></tr>
 310 <tr bgcolor="#eeeeee"><td><a href="#UPM_UNCALLED_PRIVATE_METHOD">UPM: Private method is never called</a></td><td>Performance</td></tr>
 311 <tr bgcolor="#ffffff"><td><a href="#URF_UNREAD_FIELD">UrF: Unread field</a></td><td>Performance</td></tr>
 312 <tr bgcolor="#eeeeee"><td><a href="#UUF_UNUSED_FIELD">UuF: Unused field</a></td><td>Performance</td></tr>
 313 <tr bgcolor="#ffffff"><td><a href="#WMI_WRONG_MAP_ITERATOR">WMI: Inefficient use of keySet iterator instead of entrySet iterator</a></td><td>Performance</td></tr>
 314 <tr bgcolor="#eeeeee"><td><a href="#BC_BAD_CAST_TO_ABSTRACT_COLLECTION">BC: Questionable cast to abstract collection </a></td><td>Dodgy</td></tr>
 315 <tr bgcolor="#ffffff"><td><a href="#BC_BAD_CAST_TO_CONCRETE_COLLECTION">BC: Questionable cast to concrete collection</a></td><td>Dodgy</td></tr>
 316 <tr bgcolor="#eeeeee"><td><a href="#BC_UNCONFIRMED_CAST">BC: Unchecked/unconfirmed cast</a></td><td>Dodgy</td></tr>
 317 <tr bgcolor="#ffffff"><td><a href="#BC_VACUOUS_INSTANCEOF">BC: instanceof will always return true</a></td><td>Dodgy</td></tr>
 318 <tr bgcolor="#eeeeee"><td><a href="#CI_CONFUSED_INHERITANCE">CI: Class is final but declares protected field</a></td><td>Dodgy</td></tr>
 319 <tr bgcolor="#ffffff"><td><a href="#DB_DUPLICATE_BRANCHES">DB: Method uses the same code for two branches</a></td><td>Dodgy</td></tr>
 320 <tr bgcolor="#eeeeee"><td><a href="#DB_DUPLICATE_SWITCH_CLAUSES">DB: Method uses the same code for two switch clauses</a></td><td>Dodgy</td></tr>
 321 <tr bgcolor="#ffffff"><td><a href="#DLS_DEAD_LOCAL_STORE">DLS: Dead store to local variable</a></td><td>Dodgy</td></tr>
 322 <tr bgcolor="#eeeeee"><td><a href="#DLS_DEAD_LOCAL_STORE_OF_NULL">DLS: Dead store of null to local variable</a></td><td>Dodgy</td></tr>
 323 <tr bgcolor="#ffffff"><td><a href="#DMI_HARDCODED_ABSOLUTE_FILENAME">DMI: Code contains a hard coded reference to an absolute pathname</a></td><td>Dodgy</td></tr>
 324 <tr bgcolor="#eeeeee"><td><a href="#DMI_NONSERIALIZABLE_OBJECT_WRITTEN">DMI: Non serializable object written to ObjectOutput</a></td><td>Dodgy</td></tr>
 325 <tr bgcolor="#ffffff"><td><a href="#DMI_USELESS_SUBSTRING">DMI: Invocation of substring(0), which returns the original value</a></td><td>Dodgy</td></tr>
 326 <tr bgcolor="#eeeeee"><td><a href="#DMI_THREAD_PASSED_WHERE_RUNNABLE_EXPECTED">Dm: Thread passed where Runnable expected</a></td><td>Dodgy</td></tr>
 327 <tr bgcolor="#ffffff"><td><a href="#EQ_DOESNT_OVERRIDE_EQUALS">Eq: Class doesn't override equals in superclass</a></td><td>Dodgy</td></tr>
 328 <tr bgcolor="#eeeeee"><td><a href="#FE_FLOATING_POINT_EQUALITY">FE: Test for floating point equality</a></td><td>Dodgy</td></tr>
 329 <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>
 330 <tr bgcolor="#eeeeee"><td><a href="#IC_INIT_CIRCULARITY">IC: Initialization circularity</a></td><td>Dodgy</td></tr>
 331 <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>
 332 <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>
 333 <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>
 334 <tr bgcolor="#eeeeee"><td><a href="#IM_AVERAGE_COMPUTATION_COULD_OVERFLOW">IM: Computation of average could overflow</a></td><td>Dodgy</td></tr>
 335 <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>
 336 <tr bgcolor="#eeeeee"><td><a href="#INT_VACUOUS_COMPARISON">INT: Vacuous comparison of integer value</a></td><td>Dodgy</td></tr>
 337 <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>
 338 <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>
 339 <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>
 340 <tr bgcolor="#eeeeee"><td><a href="#NP_LOAD_OF_KNOWN_NULL_VALUE">NP: Load of known null value</a></td><td>Dodgy</td></tr>
 341 <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>
 342 <tr bgcolor="#eeeeee"><td><a href="#NS_DANGEROUS_NON_SHORT_CIRCUIT">NS: Potentially dangerous use of non-short-circuit logic</a></td><td>Dodgy</td></tr>
 343 <tr bgcolor="#ffffff"><td><a href="#NS_NON_SHORT_CIRCUIT">NS: Questionable use of non-short-circuit logic</a></td><td>Dodgy</td></tr>
 344 <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>
 345 <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>
 346 <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>
 347 <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>
 348 <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>
 349 <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>
 350 <tr bgcolor="#eeeeee"><td><a href="#REC_CATCH_EXCEPTION">REC: Exception is caught when Exception is not thrown</a></td><td>Dodgy</td></tr>
 351 <tr bgcolor="#ffffff"><td><a href="#RI_REDUNDANT_INTERFACES">RI: Class implements same interface as superclass</a></td><td>Dodgy</td></tr>
 352 <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>
 353 <tr bgcolor="#ffffff"><td><a href="#RV_REM_OF_HASHCODE">RV: Remainder of hashCode could be negative</a></td><td>Dodgy</td></tr>
 354 <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>
 355 <tr bgcolor="#ffffff"><td><a href="#SA_LOCAL_SELF_ASSIGNMENT">SA: Self assignment of local variable</a></td><td>Dodgy</td></tr>
 356 <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>
 357 <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>
 358 <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>
 359 <tr bgcolor="#ffffff"><td><a href="#UCF_USELESS_CONTROL_FLOW">UCF: Useless control flow</a></td><td>Dodgy</td></tr>
 360 <tr bgcolor="#eeeeee"><td><a href="#UWF_FIELD_NOT_INITIALIZED_IN_CONSTRUCTOR">UwF: Field not initialized in constructor</a></td><td>Dodgy</td></tr>
 361 <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>
 362 </table>
 363 <h2>Descriptions</h2>
 364 <h3><a name="AM_CREATES_EMPTY_JAR_FILE_ENTRY">AM: Creates an empty jar file entry (AM_CREATES_EMPTY_JAR_FILE_ENTRY)</a></h3>
 365
 366
 367 <p>The code calls <code>putNextEntry()</code>, immediately
 368 followed by a call to <code>closeEntry()</code>. This results
 369 in an empty JarFile entry. The contents of the entry
 370 should be written to the JarFile between the calls to
 371 <code>putNextEntry()</code> and
 372 <code>closeEntry()</code>.</p>
 373
 374
 375 <h3><a name="AM_CREATES_EMPTY_ZIP_FILE_ENTRY">AM: Creates an empty zip file entry (AM_CREATES_EMPTY_ZIP_FILE_ENTRY)</a></h3>
 376
 377
 378 <p>The code calls <code>putNextEntry()</code>, immediately
 379 followed by a call to <code>closeEntry()</code>. This results
 380 in an empty ZipFile entry. The contents of the entry
 381 should be written to the ZipFile between the calls to
 382 <code>putNextEntry()</code> and
 383 <code>closeEntry()</code>.</p>
 384
 385
 386 <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>
 387
 388
 389 <p>
 390 The <code>equals(Object o)</code> method shouldn't make any assumptions
 391 about the type of <code>o</code>. It should simply return
 392 false if <code>o</code> is not the same type as <code>this</code>.
 393 </p>
 394
 395
 396 <h3><a name="DMI_RANDOM_USED_ONLY_ONCE">BC: Random object created and used only once (DMI_RANDOM_USED_ONLY_ONCE)</a></h3>
 397
 398
 399 <p> This code creates a java.util.Random object, uses it to generate one random number, and then discards
 400 the Random object. This produces mediocre quality random numbers and is inefficient.
 401 If possible, rewrite the code so that the Random object is created once and saved, and each time a new random number
 402 is required invoke a method on the existing Random object to obtain it.
 403 </p>
 404
 405 <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
 406 number; the values are too easily guessable. You should strongly consider using a java.security.SecureRandom instead
 407 (and avoid allocating a new SecureRandom for each random number needed).
 408 </p>
 409
 410
 411 <h3><a name="BIT_SIGNED_CHECK">BIT: Check for sign of bitwise operation (BIT_SIGNED_CHECK)</a></h3>
 412
 413
 414 <p> This method compares an expression such as
 415 <pre>((event.detail & SWT.SELECTED) > 0)</pre>.
 416 Using bit arithmetic and then comparing with the greater than operator can
 417 lead to unexpected results (of course depending on the value of
 418 SWT.SELECTED). If SWT.SELECTED is a negative number, this is a candidate
 419 for a bug. Even when SWT.SELECTED is not negative, it seems good practice
 420 to use '!= 0' instead of '> 0'.
 421 </p>
 422 <p>
 423 <em>Boris Bokowski</em>
 424 </p>
 425
 426
 427 <h3><a name="CN_IDIOM">CN: Class implements Cloneable but does not define or use clone method (CN_IDIOM)</a></h3>
 428
 429
 430 <p>
 431    Class implements Cloneable but does not define or
 432    use the clone method.</p>
 433
 434
 435 <h3><a name="CN_IDIOM_NO_SUPER_CALL">CN: clone method does not call super.clone() (CN_IDIOM_NO_SUPER_CALL)</a></h3>
 436
 437
 438 <p> This non-final class defines a clone() method that does not call super.clone().
 439 If this class ("<i>A</i>") is extended by a subclass ("<i>B</i>"),
 440 and the subclass <i>B</i> calls super.clone(), then it is likely that
 441 <i>B</i>'s clone() method will return an object of type <i>A</i>,
 442 which violates the standard contract for clone().</p>
 443
 444 <p> If all clone() methods call super.clone(), then they are guaranteed
 445 to use Object.clone(), which always returns an object of the correct type.</p>
 446
 447
 448 <h3><a name="CO_ABSTRACT_SELF">Co: Abstract class defines covariant compareTo() method (CO_ABSTRACT_SELF)</a></h3>
 449
 450
 451   <p> This class defines a covariant version of <code>compareTo()</code>.&nbsp;
 452   To correctly override the <code>compareTo()</code> method in the
 453   <code>Comparable</code> interface, the parameter of <code>compareTo()</code>
 454   must have type <code>java.lang.Object</code>.</p>
 455
 456
 457 <h3><a name="CO_SELF_NO_OBJECT">Co: Covariant compareTo() method defined (CO_SELF_NO_OBJECT)</a></h3>
 458
 459
 460   <p> This class defines a covariant version of <code>compareTo()</code>.&nbsp;
 461   To correctly override the <code>compareTo()</code> method in the
 462   <code>Comparable</code> interface, the parameter of <code>compareTo()</code>
 463   must have type <code>java.lang.Object</code>.</p>
 464
 465
 466 <h3><a name="DE_MIGHT_DROP">DE: Method might drop exception (DE_MIGHT_DROP)</a></h3>
 467
 468
 469   <p> This method might drop an exception.&nbsp; In general, exceptions
 470   should be handled or reported in some way, or they should be thrown
 471   out of the method.</p>
 472
 473
 474 <h3><a name="DE_MIGHT_IGNORE">DE: Method might ignore exception (DE_MIGHT_IGNORE)</a></h3>
 475
 476
 477   <p> This method might ignore an exception.&nbsp; In general, exceptions
 478   should be handled or reported in some way, or they should be thrown
 479   out of the method.</p>
 480
 481
 482 <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>
 483
 484
 485   <p> This code creates a classloader,  which requires a security manager.
 486   If this code will be granted security permissions, but might be invoked by code that does not
 487   have security permissions, then the classloader creation  needs to occur inside a doPrivileged block.</p>
 488
 489
 490 <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>
 491
 492
 493   <p> This code invokes a method that requires a security permission check.
 494   If this code will be granted security permissions, but might be invoked by code that does not
 495   have security permissions, then the invocation needs to occur inside a doPrivileged block.</p>
 496
 497
 498 <h3><a name="DM_EXIT">Dm: Method invokes System.exit(...) (DM_EXIT)</a></h3>
 499
 500
 501   <p> Invoking System.exit shuts down the entire Java virtual machine. This
 502    should only been done when it is appropriate. Such calls make it
 503    hard or impossible for your code to be invoked by other code.
 504    Consider throwing a RuntimeException instead.</p>
 505
 506
 507 <h3><a name="DM_RUN_FINALIZERS_ON_EXIT">Dm: Method invokes dangerous method runFinalizersOnExit   (DM_RUN_FINALIZERS_ON_EXIT)</a></h3>
 508
 509
 510   <p> <em>Never call System.runFinalizersOnExit
 511 or Runtime.runFinalizersOnExit for any reason: they are among the most
 512 dangerous methods in the Java libraries.</em> -- Joshua Bloch</p>
 513
 514
 515 <h3><a name="ES_COMPARING_PARAMETER_STRING_WITH_EQ">ES: Comparison of String parameter using == or != (ES_COMPARING_PARAMETER_STRING_WITH_EQ)</a></h3>
 516
 517
 518   <p>This code compares a <code>java.lang.String</code> parameter for reference
 519 equality using the == or != operators. Requiring callers to
 520 pass only String constants or interned strings to a method is unnecessarily
 521 fragile, and rarely leads to measurable performance gains. Consider
 522 using the <code>equals(Object)</code> method instead.</p>
 523
 524
 525 <h3><a name="ES_COMPARING_STRINGS_WITH_EQ">ES: Comparison of String objects using == or != (ES_COMPARING_STRINGS_WITH_EQ)</a></h3>
 526
 527
 528   <p>This code compares <code>java.lang.String</code> objects for reference
 529 equality using the == or != operators.
 530 Unless both strings are either constants in a source file, or have been
 531 interned using the <code>String.intern()</code> method, the same string
 532 value may be represented by two different String objects. Consider
 533 using the <code>equals(Object)</code> method instead.</p>
 534
 535
 536 <h3><a name="EQ_ABSTRACT_SELF">Eq: Abstract class defines covariant equals() method (EQ_ABSTRACT_SELF)</a></h3>
 537
 538
 539   <p> This class defines a covariant version of <code>equals()</code>.&nbsp;
 540   To correctly override the <code>equals()</code> method in
 541   <code>java.lang.Object</code>, the parameter of <code>equals()</code>
 542   must have type <code>java.lang.Object</code>.</p>
 543
 544
 545 <h3><a name="EQ_COMPARETO_USE_OBJECT_EQUALS">Eq: Class defines compareTo(...) and uses Object.equals() (EQ_COMPARETO_USE_OBJECT_EQUALS)</a></h3>
 546
 547
 548   <p> This class defines a <code>compareTo(...)</code> method but inherits its
 549   <code>equals()</code> method from <code>java.lang.Object</code>.
 550         Generally, the value of compareTo should return zero if and only if
 551         equals returns true. If this is violated, weird and unpredictable
 552         failures will occur in classes such as PriorityQueue.
 553         In Java 5 the PriorityQueue.remove method uses the compareTo method,
 554         while in Java 6 it uses the equals method.
 555
 556 <p>From the JavaDoc for the compareTo method in the Comparable interface:
 557 <blockquote>
 558 It is strongly recommended, but not strictly required that <code>(x.compareTo(y)==0) == (x.equals(y))</code>.
 559 Generally speaking, any class that implements the Comparable interface and violates this condition
 560 should clearly indicate this fact. The recommended language
 561 is "Note: this class has a natural ordering that is inconsistent with equals."
 562 </blockquote>
 563
 564
 565 <h3><a name="EQ_SELF_NO_OBJECT">Eq: Covariant equals() method defined (EQ_SELF_NO_OBJECT)</a></h3>
 566
 567
 568   <p> This class defines a covariant version of <code>equals()</code>.&nbsp;
 569   To correctly override the <code>equals()</code> method in
 570   <code>java.lang.Object</code>, the parameter of <code>equals()</code>
 571   must have type <code>java.lang.Object</code>.</p>
 572
 573
 574 <h3><a name="EQ_SELF_USE_OBJECT">Eq: Covariant equals() method defined, Object.equals(Object) inherited (EQ_SELF_USE_OBJECT)</a></h3>
 575
 576
 577   <p> This class defines a covariant version of the <code>equals()</code>
 578   method, but inherits the normal <code>equals(Object)</code> method
 579   defined in the base <code>java.lang.Object</code> class.&nbsp;
 580   The class should probably define a non-covariant version of <code>equals()</code>.&nbsp;
 581   (I.e., a method with the signature <code>boolean equals(java.lang.Object)</code>.</p>
 582
 583
 584 <h3><a name="FI_EMPTY">FI: Empty finalizer should be deleted (FI_EMPTY)</a></h3>
 585
 586
 587   <p> Empty <code>finalize()</code> methods are useless, so they should
 588   be deleted.</p>
 589
 590
 591 <h3><a name="FI_EXPLICIT_INVOCATION">FI: Explicit invocation of finalizer (FI_EXPLICIT_INVOCATION)</a></h3>
 592
 593
 594   <p> This method contains an explicit invocation of the <code>finalize()</code>
 595   method on an object.&nbsp; Because finalizer methods are supposed to be
 596   executed once, and only by the VM, this is a bad idea.</p>
 597 <p>If a connected set of objects beings finalizable, then the VM will invoke the
 598 finalize method on all the finalizable object, possibly at the same time in different threads.
 599 Thus, it is a particularly bad idea, in the finalize method for a class X, invoke finalize
 600 on objects referenced by X, because they may already be getting finalized in a separate thread.
 601
 602
 603 <h3><a name="FI_FINALIZER_NULLS_FIELDS">FI: Finalizer nulls fields (FI_FINALIZER_NULLS_FIELDS)</a></h3>
 604
 605
 606   <p> This finalizer nulls out fields.  This is usually an error, as it does not aid garbage collection,
 607   and the object is going to be garbage collected anyway.
 608
 609
 610 <h3><a name="FI_FINALIZER_ONLY_NULLS_FIELDS">FI: Finalizer only nulls fields (FI_FINALIZER_ONLY_NULLS_FIELDS)</a></h3>
 611
 612
 613   <p> This finalizer does nothing except null out fields. This is completely pointless, and requires that
 614 the object be garbage collected, finalized, and then garbage collected again. You should just remove the finalize
 615 method.
 616
 617
 618 <h3><a name="FI_MISSING_SUPER_CALL">FI: Finalizer does not call superclass finalizer (FI_MISSING_SUPER_CALL)</a></h3>
 619
 620
 621   <p> This <code>finalize()</code> method does not make a call to its
 622   superclass's <code>finalize()</code> method.&nbsp; So, any finalizer
 623   actions defined for the superclass will not be performed.&nbsp;
 624   Add a call to <code>super.finalize()</code>.</p>
 625
 626
 627 <h3><a name="FI_NULLIFY_SUPER">FI: Finalizer nullifies superclass finalizer (FI_NULLIFY_SUPER)</a></h3>
 628
 629
 630   <p> This empty <code>finalize()</code> method explicitly negates the
 631   effect of any finalizer defined by its superclass.&nbsp; Any finalizer
 632   actions defined for the superclass will not be performed.&nbsp;
 633   Unless this is intended, delete this method.</p>
 634
 635
 636 <h3><a name="FI_USELESS">FI: Finalizer does nothing but call superclass finalizer (FI_USELESS)</a></h3>
 637
 638
 639   <p> The only thing this <code>finalize()</code> method does is call
 640   the superclass's <code>finalize()</code> method, making it
 641   redundant.&nbsp; Delete it.</p>
 642
 643
 644 <h3><a name="HE_EQUALS_NO_HASHCODE">HE: Class defines equals() but not hashCode() (HE_EQUALS_NO_HASHCODE)</a></h3>
 645
 646
 647   <p> This class overrides <code>equals(Object)</code>, but does not
 648   override <code>hashCode()</code>.&nbsp; Therefore, the class may violate the
 649   invariant that equal objects must have equal hashcodes.</p>
 650
 651
 652 <h3><a name="HE_EQUALS_USE_HASHCODE">HE: Class defines equals() and uses Object.hashCode() (HE_EQUALS_USE_HASHCODE)</a></h3>
 653
 654
 655   <p> This class overrides <code>equals(Object)</code>, but does not
 656   override <code>hashCode()</code>, and inherits the implementation of
 657   <code>hashCode()</code> from <code>java.lang.Object</code> (which returns
 658   the identity hash code, an arbitrary value assigned to the object
 659   by the VM).&nbsp; Therefore, the class is very likely to violate the
 660   invariant that equal objects must have equal hashcodes.</p>
 661
 662 <p>If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
 663 the recommended <code>hashCode</code> implementation to use is:</p>
 664 <pre>public int hashCode() {
 665   assert false : "hashCode not designed";
 666   return 42; // any arbitrary constant will do
 667   }</pre>
 668
 669
 670 <h3><a name="HE_HASHCODE_NO_EQUALS">HE: Class defines hashCode() but not equals() (HE_HASHCODE_NO_EQUALS)</a></h3>
 671
 672
 673   <p> This class defines a <code>hashCode()</code> method but not an
 674   <code>equals()</code> method.&nbsp; Therefore, the class may
 675   violate the invariant that equal objects must have equal hashcodes.</p>
 676
 677
 678 <h3><a name="HE_HASHCODE_USE_OBJECT_EQUALS">HE: Class defines hashCode() and uses Object.equals() (HE_HASHCODE_USE_OBJECT_EQUALS)</a></h3>
 679
 680
 681   <p> This class defines a <code>hashCode()</code> method but inherits its
 682   <code>equals()</code> method from <code>java.lang.Object</code>
 683   (which defines equality by comparing object references).&nbsp; Although
 684   this will probably satisfy the contract that equal objects must have
 685   equal hashcodes, it is probably not what was intended by overriding
 686   the <code>hashCode()</code> method.&nbsp; (Overriding <code>hashCode()</code>
 687   implies that the object's identity is based on criteria more complicated
 688   than simple reference equality.)</p>
 689 <p>If you don't think instances of this class will ever be inserted into a HashMap/HashTable,
 690 the recommended <code>hashCode</code> implementation to use is:</p>
 691 <p><pre>public int hashCode() {
 692   assert false : "hashCode not designed";
 693   return 42; // any arbitrary constant will do
 694   }</pre></p>
 695
 696
 697 <h3><a name="HE_INHERITS_EQUALS_USE_HASHCODE">HE: Class inherits equals() and uses Object.hashCode() (HE_INHERITS_EQUALS_USE_HASHCODE)</a></h3>
 698
 699
 700   <p> This class inherits <code>equals(Object)</code> from an abstract
 701   superclass, and <code>hashCode()</code> from
 702 <code>java.lang.Object</code> (which returns
 703   the identity hash code, an arbitrary value assigned to the object
 704   by the VM).&nbsp; Therefore, the class is very likely to violate the
 705   invariant that equal objects must have equal hashcodes.</p>
 706
 707   <p>If you don't want to define a hashCode method, and/or don't
 708    believe the object will ever be put into a HashMap/Hashtable,
 709    define the <code>hashCode()</code> method
 710    to throw <code>UnsupportedOperationException</code>.</p>
 711
 712
 713 <h3><a name="IC_SUPERCLASS_USES_SUBCLASS_DURING_INITIALIZATION">IC: Superclass uses subclass during initialization (IC_SUPERCLASS_USES_SUBCLASS_DURING_INITIALIZATION)</a></h3>
 714
 715
 716   <p> During the initialization of a class, the class makes an active use of a subclass.
 717 That subclass will not yet be initialized at the time of this use.
 718 For example, in the following code, <code>foo</code> will be null.</p>
 719
 720 <pre>
 721 public class CircularClassInitialization {
 722         static class InnerClassSingleton extends CircularClassInitialization {
 723                 static InnerClassSingleton singleton = new InnerClassSingleton();
 724         }
 725
 726         static CircularClassInitialization foo = InnerClassSingleton.singleton;
 727 }
 728 </pre>
 729
 730
 731
 732 <h3><a name="IMSE_DONT_CATCH_IMSE">IMSE: Dubious catching of IllegalMonitorStateException (IMSE_DONT_CATCH_IMSE)</a></h3>
 733
 734
 735 <p>IllegalMonitorStateException is generally only
 736    thrown in case of a design flaw in your code (calling wait or
 737    notify on an object you do not hold a lock on).</p>
 738
 739
 740 <h3><a name="ISC_INSTANTIATE_STATIC_CLASS">ISC: Needless instantiation of class that only supplies static methods (ISC_INSTANTIATE_STATIC_CLASS)</a></h3>
 741
 742
 743 <p> This class allocates an object that is based on a class that only supplies static methods. This object
 744 does not need to be created, just access the static methods directly using the class name as a qualifier.</p>
 745
 746
 747 <h3><a name="IT_NO_SUCH_ELEMENT">It: Iterator next() method can't throw NoSuchElement exception (IT_NO_SUCH_ELEMENT)</a></h3>
 748
 749
 750   <p> This class implements the <code>java.util.Iterator</code> interface.&nbsp;
 751   However, its <code>next()</code> method is not capable of throwing
 752   <code>java.util.NoSuchElementException</code>.&nbsp; The <code>next()</code>
 753   method should be changed so it throws <code>NoSuchElementException</code>
 754   if is called when there are no more elements to return.</p>
 755
 756
 757 <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>
 758
 759
 760 <p>
 761 This code seems to be storing a non-serializable object into an HttpSession.
 762 If this session is passivated or migrated, an error will result.
 763 </p>
 764
 765
 766 <h3><a name="NP_CLONE_COULD_RETURN_NULL">NP: Clone method may return null (NP_CLONE_COULD_RETURN_NULL)</a></h3>
 767
 768
 769       <p>
 770         This clone method seems to return null in some circumstances, but clone is never
 771         allowed to return a null value.  If you are convinced this path is unreachable, throw an AssertionError
 772         instead.
 773       </p>
 774
 775
 776 <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>
 777
 778
 779       <p>
 780       This implementation of equals(Object) violates the contract defined
 781       by java.lang.Object.equals() because it does not check for null
 782       being passed as the argument.  All equals() methods should return
 783       false if passed a null value.
 784       </p>
 785
 786
 787 <h3><a name="NP_TOSTRING_COULD_RETURN_NULL">NP: toString method may return null (NP_TOSTRING_COULD_RETURN_NULL)</a></h3>
 788
 789
 790       <p>
 791         This toString method seems to return null in some circumstances. A liberal reading of the
 792         spec could be interpreted as allowing this, but it is probably a bad idea and could cause
 793         other code to break. Return the empty string or some other appropriate string rather than null.
 794       </p>
 795
 796
 797 <h3><a name="NM_CLASS_NAMING_CONVENTION">Nm: Class names should start with an upper case letter (NM_CLASS_NAMING_CONVENTION)</a></h3>
 798
 799
 800   <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).
 801 </p>
 802
 803
 804 <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>
 805
 806
 807 <p> This class is not derived from another exception, but ends with 'Exception'. This will
 808 be confusing to users of this class.</p>
 809
 810
 811 <h3><a name="NM_CONFUSING">Nm: Confusing method names (NM_CONFUSING)</a></h3>
 812
 813
 814   <p> The referenced methods have names that differ only by capitalization.</p>
 815
 816
 817 <h3><a name="NM_FIELD_NAMING_CONVENTION">Nm: Field names should start with an lower case letter (NM_FIELD_NAMING_CONVENTION)</a></h3>
 818
 819
 820   <p>
 821 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.
 822 </p>
 823
 824
 825 <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>
 826
 827
 828 <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
 829 in order to compile it in later versions of Java.</p>
 830
 831
 832
 833 <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>
 834
 835
 836 <p>This identifier is used as a keyword in later versions of Java. This code, and
 837 any code that references this API,
 838 will need to be changed  in order to compile it in later versions of Java.</p>
 839
 840
 841
 842 <h3><a name="NM_METHOD_NAMING_CONVENTION">Nm: Method names should start with an lower case letter (NM_METHOD_NAMING_CONVENTION)</a></h3>
 843
 844
 845   <p>
 846 Methods should be verbs, in mixed case with the first letter lowercase, with the first letter of each internal word capitalized.
 847 </p>
 848
 849
 850 <h3><a name="NM_SAME_SIMPLE_NAME_AS_INTERFACE">Nm: Class names shouldn't shadow simple name of implemented interface (NM_SAME_SIMPLE_NAME_AS_INTERFACE)</a></h3>
 851
 852
 853   <p> This class/interface has a simple name that is identical to that of an implemented/extended  interface, except
 854 that the interface is in a different package (e.g., <code>alpha.Foo</code> extends <code>beta.Foo</code>).
 855 This can be exceptionally confusing, create lots of situations in which you have to look at import statements
 856 to resolve references and creates many
 857 opportunities to accidently define methods that do not override methods in their superclasses.
 858 </p>
 859
 860
 861 <h3><a name="NM_SAME_SIMPLE_NAME_AS_SUPERCLASS">Nm: Class names shouldn't shadow simple name of superclass (NM_SAME_SIMPLE_NAME_AS_SUPERCLASS)</a></h3>
 862
 863
 864   <p> This class has a simple name that is identical to that of its superclass, except
 865 that its superclass is in a different package (e.g., <code>alpha.Foo</code> extends <code>beta.Foo</code>).
 866 This can be exceptionally confusing, create lots of situations in which you have to look at import statements
 867 to resolve references and creates many
 868 opportunities to accidently define methods that do not override methods in their superclasses.
 869 </p>
 870
 871
 872 <h3><a name="NM_VERY_CONFUSING_INTENTIONAL">Nm: Very confusing method names (NM_VERY_CONFUSING_INTENTIONAL)</a></h3>
 873
 874
 875   <p> The referenced methods have names that differ only by capitalization.
 876 This is very confusing because if the capitalization were
 877 identical then one of the methods would override the other. From the existence of other methods, it
 878 seems that the existence of both of these methods is intentional, but is sure is confusing.
 879 You should try hard to eliminate one of them, unless you are forced to have both due to frozen APIs.
 880 </p>
 881
 882
 883 <h3><a name="NM_WRONG_PACKAGE_INTENTIONAL">Nm: Method doesn't override method in superclass due to wrong package for parameter (NM_WRONG_PACKAGE_INTENTIONAL)</a></h3>
 884
 885
 886   <p> The method in the subclass doesn't override a similar method in a superclass because the type of a parameter doesn't exactly match
 887 the type of the corresponding parameter in the superclass. For example, if you have:</p>
 888
 889 <blockquote>
 890 <pre>
 891 import alpha.Foo;
 892 public class A {
 893   public int f(Foo x) { return 17; }
 894 }
 895 ----
 896 import beta.Foo;
 897 public class B extends A {
 898   public int f(Foo x) { return 42; }
 899   public int f(alpha.Foo x) { return 27; }
 900 }
 901 </pre>
 902 </blockquote>
 903
 904 <p>The <code>f(Foo)</code> method defined in class <code>B</code> doesn't
 905 override the
 906 <code>f(Foo)</code> method defined in class <code>A</code>, because the argument
 907 types are <code>Foo</code>'s from different packages.
 908 </p>
 909
 910 <p>In this case, the subclass does define a method with a signature identical to the method in the superclass,
 911 so this is presumably understood. However, such methods are exceptionally confusing. You should strongly consider
 912 removing or deprecating the method with the similar but not identical signature.
 913 </p>
 914
 915
 916 <h3><a name="ODR_OPEN_DATABASE_RESOURCE">ODR: Method may fail to close database resource (ODR_OPEN_DATABASE_RESOURCE)</a></h3>
 917
 918
 919 <p> The method creates a database resource (such as a database connection
 920 or row set), does not assign it to any
 921 fields, pass it to other methods, or return it, and does not appear to close
 922 the object on all paths out of the method.&nbsp; Failure to
 923 close database resources on all paths out of a method may
 924 result in poor performance, and could cause the application to
 925 have problems communicating with the database.
 926 </p>
 927
 928
 929 <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>
 930
 931
 932 <p> The method creates a database resource (such as a database connection
 933 or row set), does not assign it to any
 934 fields, pass it to other methods, or return it, and does not appear to close
 935 the object on all exception paths out of the method.&nbsp; Failure to
 936 close database resources on all paths out of a method may
 937 result in poor performance, and could cause the application to
 938 have problems communicating with the database.</p>
 939
 940
 941 <h3><a name="OS_OPEN_STREAM">OS: Method may fail to close stream (OS_OPEN_STREAM)</a></h3>
 942
 943
 944 <p> The method creates an IO stream object, does not assign it to any
 945 fields, pass it to other methods that might close it,
 946 or return it, and does not appear to close
 947 the stream on all paths out of the method.&nbsp; This may result in
 948 a file descriptor leak.&nbsp; It is generally a good
 949 idea to use a <code>finally</code> block to ensure that streams are
 950 closed.</p>
 951
 952
 953 <h3><a name="OS_OPEN_STREAM_EXCEPTION_PATH">OS: Method may fail to close stream on exception (OS_OPEN_STREAM_EXCEPTION_PATH)</a></h3>
 954
 955
 956 <p> The method creates an IO stream object, does not assign it to any
 957 fields, pass it to other methods, or return it, and does not appear to close
 958 it on all possible exception paths out of the method.&nbsp;
 959 This may result in a file descriptor leak.&nbsp; It is generally a good
 960 idea to use a <code>finally</code> block to ensure that streams are
 961 closed.</p>
 962
 963
 964 <h3><a name="RC_REF_COMPARISON">RC: Suspicious reference comparison (RC_REF_COMPARISON)</a></h3>
 965
 966
 967 <p> This method compares two reference values using the == or != operator,
 968 where the correct way to compare instances of this type is generally
 969 with the equals() method.  Examples of classes which should generally
 970 not be compared by reference are java.lang.Integer, java.lang.Float, etc.</p>
 971
 972
 973 <h3><a name="RR_NOT_CHECKED">RR: Method ignores results of InputStream.read() (RR_NOT_CHECKED)</a></h3>
 974
 975
 976   <p> This method ignores the return value of one of the variants of
 977   <code>java.io.InputStream.read()</code> which can return multiple bytes.&nbsp;
 978   If the return value is not checked, the caller will not be able to correctly
 979   handle the case where fewer bytes were read than the caller requested.&nbsp;
 980   This is a particularly insidious kind of bug, because in many programs,
 981   reads from input streams usually do read the full amount of data requested,
 982   causing the program to fail only sporadically.</p>
 983
 984
 985 <h3><a name="SR_NOT_CHECKED">RR: Method ignores results of InputStream.skip() (SR_NOT_CHECKED)</a></h3>
 986
 987
 988   <p> This method ignores the return value of
 989   <code>java.io.InputStream.skip()</code> which can skip multiple bytes.&nbsp;
 990   If the return value is not checked, the caller will not be able to correctly
 991   handle the case where fewer bytes were skipped than the caller requested.&nbsp;
 992   This is a particularly insidious kind of bug, because in many programs,
 993   skips from input streams usually do skip the full amount of data requested,
 994   causing the program to fail only sporadically. With Buffered streams, however,
 995   skip() will only skip data in the buffer, and will routinely fail to skip the
 996   requested number of bytes.</p>
 997
 998
 999 <h3><a name="RV_RETURN_VALUE_IGNORED_BAD_PRACTICE">RV: Method ignores return value (RV_RETURN_VALUE_IGNORED_BAD_PRACTICE)</a></h3>
1000
1001
1002    <p> This method returns a value that is not checked. For
1003 example, the <code>File.delete()</code> method returns false
1004 if the file could not be successfully deleted (rather than
1005 throwing an Exception).
1006 If you don't check the result, you won't notice if the method invocation
1007 signals unexpected behavior by returning an atypical return value.
1008
1009
1010 <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>
1011
1012
1013 <p> The class's static initializer creates an instance of the class
1014 before all of the static final fields are assigned.</p>
1015
1016
1017 <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>
1018
1019
1020   <p>The method invokes the execute method on an SQL statement with a String that seems
1021 to be dynamically generated. Consider using
1022 a prepared statement instead. It is more efficient and less vulnerable to
1023 SQL injection attacks.
1024 </p>
1025
1026
1027 <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>
1028
1029
1030   <p>The code creates an SQL prepared statement from a nonconstant String.
1031 If unchecked, tainted data from a user is used in building this String, SQL injection could
1032 be used to make the prepared statement do something unexpected and undesirable.
1033 </p>
1034
1035
1036 <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>
1037
1038
1039 <p>(<a href="http://java.sun.com/developer/JDCTechTips/2003/tt1208.html#1">From JDC Tech Tip</a>): The Swing methods
1040 show(), setVisible(), and pack() will create the associated peer for the frame.
1041 With the creation of the peer, the system creates the event dispatch thread.
1042 This makes things problematic because the event dispatch thread could be notifying
1043 listeners while pack and validate are still processing. This situation could result in
1044 two threads going through the Swing component-based GUI -- it's a serious flaw that
1045 could result in deadlocks or other related threading issues. A pack call causes
1046 components to be realized. As they are being realized (that is, not necessarily
1047 visible), they could trigger listener notification on the event dispatch thread.</p>
1048
1049
1050
1051 <h3><a name="SE_BAD_FIELD">Se: Non-transient non-serializable instance field in serializable class (SE_BAD_FIELD)</a></h3>
1052
1053
1054 <p> This Serializable class defines a non-primitive instance field which is neither transient,
1055 Serializable, or <code>java.lang.Object</code>, and does not appear to implement
1056 the <code>Externalizable</code> interface or the
1057 <code>readObject()</code> and <code>writeObject()</code> methods.&nbsp;
1058 Objects of this class will not be deserialized correctly if a non-Serializable
1059 object is stored in this field.</p>
1060
1061
1062 <h3><a name="SE_BAD_FIELD_INNER_CLASS">Se: Non-serializable class has a serializable inner class (SE_BAD_FIELD_INNER_CLASS)</a></h3>
1063
1064
1065 <p> This Serializable class is an inner class of a non-serializable class.
1066 Thus, attempts to serialize it will also attempt to associate instance of the outer
1067 class with which it is associated, leading to a runtime error.
1068 </p>
1069 <p>If possible, making the inner class a static inner class should solve the
1070 problem. Making the outer class serializable might also work, but that would
1071 mean serializing an instance of the inner class would always also serialize the instance
1072 of the outer class, which it often not what you really want.
1073
1074
1075 <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>
1076
1077
1078 <p> A non-serializable value is stored into a non-transient field
1079 of a serializable class.</p>
1080
1081
1082 <h3><a name="SE_COMPARATOR_SHOULD_BE_SERIALIZABLE">Se: Comparator doesn't implement Serializable (SE_COMPARATOR_SHOULD_BE_SERIALIZABLE)</a></h3>
1083
1084
1085   <p> This class implements the <code>Comparator</code> interface. You
1086 should consider whether or not it should also implement the <code>Serializable</code>
1087 interface. If a comparator is used to construct an ordered collection
1088 such as a <code>TreeMap</code>, then the <code>TreeMap</code>
1089 will be serializable only if the comparator is also serializable.
1090 As most comparators have little or no state, making them serializable
1091 is generally easy and good defensive programming.
1092 </p>
1093
1094
1095 <h3><a name="SE_INNER_CLASS">Se: Serializable inner class (SE_INNER_CLASS)</a></h3>
1096
1097
1098 <p> This Serializable class is an inner class.  Any attempt to serialize
1099 it will also serialize the associated outer instance. The outer instance is serializable,
1100 so this won't fail, but it might serialize a lot more data than intended.
1101 If possible, making the inner class a static inner class (also known as a nested class) should solve the
1102 problem.
1103
1104
1105 <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>
1106
1107
1108   <p> This class implements the <code>Serializable</code> interface, and defines a method
1109   for custom  serialization/deserialization. But since that method isn't declared private,
1110   it will be silently ignored by the serialization/deserialization API.</p>
1111
1112
1113 <h3><a name="SE_NONFINAL_SERIALVERSIONID">Se: serialVersionUID isn't final (SE_NONFINAL_SERIALVERSIONID)</a></h3>
1114
1115
1116   <p> This class defines a <code>serialVersionUID</code> field that is not final.&nbsp;
1117   The field should be made final
1118    if it is intended to specify
1119    the version UID for purposes of serialization.</p>
1120
1121
1122 <h3><a name="SE_NONLONG_SERIALVERSIONID">Se: serialVersionUID isn't long (SE_NONLONG_SERIALVERSIONID)</a></h3>
1123
1124
1125   <p> This class defines a <code>serialVersionUID</code> field that is not long.&nbsp;
1126   The field should be made long
1127    if it is intended to specify
1128    the version UID for purposes of serialization.</p>
1129
1130
1131 <h3><a name="SE_NONSTATIC_SERIALVERSIONID">Se: serialVersionUID isn't static (SE_NONSTATIC_SERIALVERSIONID)</a></h3>
1132
1133
1134   <p> This class defines a <code>serialVersionUID</code> field that is not static.&nbsp;
1135   The field should be made static
1136    if it is intended to specify
1137    the version UID for purposes of serialization.</p>
1138
1139
1140 <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>
1141
1142
1143   <p> This class implements the <code>Serializable</code> interface
1144    and its superclass does not. When such an object is deserialized,
1145    the fields of the superclass need to be initialized by
1146    invoking the void constructor of the superclass.
1147    Since the superclass does not have one,
1148    serialization and deserialization will fail at runtime.</p>
1149
1150
1151 <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>
1152
1153
1154   <p> This class implements the <code>Externalizable</code> interface, but does
1155   not define a void constructor. When Externalizable objects are deserialized,
1156    they first need to be constructed by invoking the void
1157    constructor. Since this class does not have one,
1158    serialization and deserialization will fail at runtime.</p>
1159
1160
1161 <h3><a name="SE_READ_RESOLVE_MUST_RETURN_OBJECT">Se: The readResolve method must be declared with a return type
1162 of Object.  (SE_READ_RESOLVE_MUST_RETURN_OBJECT)</a></h3>
1163
1164
1165   <p> In order for the readResolve method to be recognized by the serialization
1166 mechanism.
1167 </p>
1168
1169
1170 <h3><a name="SE_TRANSIENT_FIELD_NOT_RESTORED">Se: Transient field that isn't set by deserialization.  (SE_TRANSIENT_FIELD_NOT_RESTORED)</a></h3>
1171
1172
1173   <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
1174 deserialized instance of the class.
1175 </p>
1176
1177
1178 <h3><a name="SE_NO_SERIALVERSIONID">SnVI: Class is Serializable, but doesn't define serialVersionUID (SE_NO_SERIALVERSIONID)</a></h3>
1179
1180
1181   <p> This class implements the <code>Serializable</code> interface, but does
1182   not define a <code>serialVersionUID</code> field.&nbsp;
1183   A change as simple as adding a reference to a .class object
1184     will add synthetic fields to the class,
1185    which will unfortunately change the implicit
1186    serialVersionUID (e.g., adding a reference to <code>String.class</code>
1187    will generate a static field <code>class$java$lang$String</code>).
1188    Also, different source code to bytecode compilers may use different
1189    naming conventions for synthetic variables generated for
1190    references to class objects or inner classes.
1191    To ensure interoperability of Serializable across versions,
1192    consider adding an explicit serialVersionUID.</p>
1193
1194
1195 <h3><a name="UI_INHERITANCE_UNSAFE_GETRESOURCE">UI: Usage of GetResource may be unsafe if class is extended (UI_INHERITANCE_UNSAFE_GETRESOURCE)</a></h3>
1196
1197
1198 <p>Calling <code>this.getClass().getResource(...)</code> could give
1199 results other than expected if this class is extended by a class in
1200 another package.</p>
1201
1202
1203 <h3><a name="BC_IMPOSSIBLE_CAST">BC: Impossible cast (BC_IMPOSSIBLE_CAST)</a></h3>
1204
1205
1206 <p>
1207 This cast will always throw a ClassCastException.
1208 </p>
1209
1210
1211 <h3><a name="BC_IMPOSSIBLE_INSTANCEOF">BC: instanceof will always return false (BC_IMPOSSIBLE_INSTANCEOF)</a></h3>
1212
1213
1214 <p>
1215 This instanceof test will always return false. Although this is safe, make sure it isn't
1216 an indication of some misunderstanding or some other logic error.
1217 </p>
1218
1219
1220 <h3><a name="BIT_AND">BIT: Incompatible bit masks (BIT_AND)</a></h3>
1221
1222
1223 <p> This method compares an expression of the form (a &amp; C) to D,
1224 which will always compare unequal
1225 due to the specific values of constants C and D.
1226 This may indicate a logic error or typo.</p>
1227
1228
1229 <h3><a name="BIT_AND_ZZ">BIT: Check to see if ((...) & 0) == 0 (BIT_AND_ZZ)</a></h3>
1230
1231
1232 <p> This method compares an expression of the form (a &amp; 0) to 0,
1233 which will always compare equal.
1234 This may indicate a logic error or typo.</p>
1235
1236
1237 <h3><a name="BIT_IOR">BIT: Incompatible bit masks (BIT_IOR)</a></h3>
1238
1239
1240 <p> This method compares an expression of the form (a | C) to D.
1241 which will always compare unequal
1242 due to the specific values of constants C and D.
1243 This may indicate a logic error or typo.</p>
1244
1245 <p> Typically, this bug occurs because the code wants to perform
1246 a membership test in a bit set, but uses the bitwise OR
1247 operator ("|") instead of bitwise AND ("&amp;").</p>
1248
1249
1250 <h3><a name="BIT_IOR_OF_SIGNED_BYTE">BIT: Bitwise OR of signed byte value (BIT_IOR_OF_SIGNED_BYTE)</a></h3>
1251
1252
1253 <p> Loads a value from a byte array and performs a bitwise OR with
1254 that value. Values loaded from a byte array are sign extended to 32 bits
1255 before any any bitwise operations are performed on the value.
1256 Thus, if <code>b[0]</code> contains the value <code>0xff</code>, and
1257 <code>x</code> is initially 0, then the code
1258 <code>((x << 8) | b[0])</code>  will sign extend <code>0xff</code>
1259 to get <code>0xffffffff</code>, and thus give the value
1260 <code>0xffffffff</code> as the result.
1261 </p>
1262
1263 <p>In particular, the following code for packing a byte array into an int is badly wrong: </p>
1264 <code>
1265 int result = 0;
1266 for(int i = 0; i < 4; i++)
1267   result = ((result << 8) | b[i]);
1268 </code>
1269
1270 <p>The following idiom will work instead: </p>
1271 <code>
1272 int result = 0;
1273 for(int i = 0; i < 4; i++)
1274   result = ((result << 8) | (b[i] &amps; 0xff));
1275 </code>
1276
1277
1278
1279 <h3><a name="BIT_SIGNED_CHECK_HIGH_BIT">BIT: Check for sign of bitwise operation (BIT_SIGNED_CHECK_HIGH_BIT)</a></h3>
1280
1281
1282 <p> This method compares an expression such as
1283 <pre>((event.detail & SWT.SELECTED) > 0)</pre>.
1284 Using bit arithmetic and then comparing with the greater than operator can
1285 lead to unexpected results (of course depending on the value of
1286 SWT.SELECTED). If SWT.SELECTED is a negative number, this is a candidate
1287 for a bug. Even when SWT.SELECTED is not negative, it seems good practice
1288 to use '!= 0' instead of '> 0'.
1289 </p>
1290 <p>
1291 <em>Boris Bokowski</em>
1292 </p>
1293
1294
1295 <h3><a name="BOA_BADLY_OVERRIDDEN_ADAPTER">BOA: Class overrides a method implemented in super class Adapter wrongly (BOA_BADLY_OVERRIDDEN_ADAPTER)</a></h3>
1296
1297
1298 <p> This method overrides a method found in a parent class, where that class is an Adapter that implements
1299 a listener defined in the java.awt.event or javax.swing.event package. As a result, this method will not
1300 get called when the event occurs.</p>
1301
1302
1303 <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>
1304
1305
1306   <p>A wrapped primative value is unboxed and converted to another primative type as part of the
1307 evaluation of a conditional ternary operator (the <code> b ? e1 : e2</code> operator). The
1308 semantics of Java mandate that if <code>e1</code> and <code>e2</code> are wrapped
1309 numeric values, the values are unboxed and converted/coerced to their common  type (e.g,
1310 if <code>e1</code> is of type <code>Integer</code>
1311 and <code>e2</code> is of type <code>Float</code>, then <code>e1</code> is unboxed,
1312 converted to a floating point value, and boxed. See JLS Section 15.25.
1313 </p>
1314
1315
1316 <h3><a name="DLS_DEAD_STORE_OF_CLASS_LITERAL">DLS: Dead store of class literal (DLS_DEAD_STORE_OF_CLASS_LITERAL)</a></h3>
1317
1318
1319 <p>
1320 This instruction assigns a class literal to a variable and then never uses it.
1321 <a href="//java.sun.com/j2se/1.5.0/compatibility.html#literal">The behavior of this differs in Java 1.4 and in Java 5.</a>
1322 In Java 1.4 and earlier, a reference to <code>Foo.class</code> would force the static initializer
1323 for <code>Foo</code> to be executed, if it has not been executed already.
1324 In Java 5 and later, it does not.
1325 </p>
1326 <p>See Sun's <a href="//java.sun.com/j2se/1.5.0/compatibility.html#literal">article on Java SE compatibility</a>
1327 for more details and examples, and suggestions on how to force class initialization in Java 5.
1328 </p>
1329
1330
1331 <h3><a name="DLS_OVERWRITTEN_INCREMENT">DLS: Overwritten increment (DLS_OVERWRITTEN_INCREMENT)</a></h3>
1332
1333
1334 <p>
1335 The code performs an increment operation (e.g., <code>i++</code>) and then
1336 immediately overwrites it. For example, <code>i = i++</code> immediately
1337 overwrites the incremented value with the original value.
1338 </p>
1339
1340
1341 <h3><a name="DMI_BAD_MONTH">DMI: Bad constant value for month (DMI_BAD_MONTH)</a></h3>
1342
1343
1344 <p>
1345 This code passes a constant month
1346 value outside the expected range of 0..11 to a method.
1347 </p>
1348
1349
1350 <h3><a name="DMI_CALLING_NEXT_FROM_HASNEXT">DMI: hasNext method invokes next (DMI_CALLING_NEXT_FROM_HASNEXT)</a></h3>
1351
1352
1353 <p>
1354 The hasNext() method invokes the next() method. This is almost certainly wrong,
1355 since the hasNext() method is not supposed to change the state of the iterator,
1356 and the next method is supposed to change the state of the iterator.
1357 </p>
1358
1359
1360 <h3><a name="DMI_INVOKING_TOSTRING_ON_ARRAY">DMI: Invocation of toString on an array (DMI_INVOKING_TOSTRING_ON_ARRAY)</a></h3>
1361
1362
1363 <p>
1364 The code invokes toString on an array, which will generate a fairly useless result
1365 such as [C@16f0472. Consider using Arrays.toString to convert the array into a readable
1366 String that gives the contents of the array. See Programming Puzzlers, chapter 3, puzzle 12.
1367 </p>
1368
1369
1370 <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>
1371
1372
1373 <p> The Double.longBitsToDouble method is invoked, but a 32 bit int value is passed
1374         as an argument. This almostly certainly is not intended and is unlikely
1375         to give the intended result.
1376 </p>
1377
1378
1379 <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>
1380
1381
1382   <p> Unless an annotation has itself been annotated with a @Retention other than the default
1383 of source-only retention, the annotation isn't retained in the classfile and can't be observed using reflection
1384         (e.g., by using the isAnnotationPresent method).
1385    .</p>
1386
1387
1388 <h3><a name="EC_ARRAY_AND_NONARRAY">EC: equals() used to compare array and nonarray (EC_ARRAY_AND_NONARRAY)</a></h3>
1389
1390
1391 <p>
1392 This method invokes the .equals(Object o) to compare an array and a reference that doesn't seem
1393 to be an array. If things being compared are of different types, they are guaranteed to be unequal
1394 and the comparison is almost certainly an error. Even if they are both arrays, the equals method
1395 on arrays only determines of the two arrays are the same object.
1396 To compare the
1397 contents of the arrays, use java.util.Arrays.equals(Object[], Object[]).
1398 </p>
1399
1400
1401 <h3><a name="EC_BAD_ARRAY_COMPARE">EC: Invocation of equals() on an array, which is equivalent to == (EC_BAD_ARRAY_COMPARE)</a></h3>
1402
1403
1404 <p>
1405 This method invokes the .equals(Object o) method on an array. Since arrays do not override the equals
1406 method of Object, calling equals on an array is the same as comparing their addresses. To compare the
1407 contents of the arrays, use java.util.Arrays.equals(Object[], Object[]).
1408 </p>
1409
1410
1411 <h3><a name="EC_NULL_ARG">EC: Call to equals() with null argument (EC_NULL_ARG)</a></h3>
1412
1413
1414 <p> This method calls equals(Object), passing a null value as
1415 the argument. According to the contract of the equals() method,
1416 this call should always return <code>false</code>.</p>
1417
1418
1419 <h3><a name="EC_UNRELATED_CLASS_AND_INTERFACE">EC: Call to equals() comparing unrelated class and interface (EC_UNRELATED_CLASS_AND_INTERFACE)</a></h3>
1420
1421
1422 <p>
1423 This method calls equals(Object) on two references,  one of which is a class
1424 and the other an interface, where neither the class nor any of its
1425 non-abstract subclasses implement the interface.
1426 Therefore, the objects being compared
1427 are unlikely to be members of the same class at runtime
1428 (unless some application classes were not analyzed, or dynamic class
1429 loading can occur at runtime).
1430 According to the contract of equals(),
1431 objects of different
1432 classes should always compare as unequal; therefore, according to the
1433 contract defined by java.lang.Object.equals(Object),
1434 the result of this comparison will always be false at runtime.
1435 </p>
1436
1437
1438 <h3><a name="EC_UNRELATED_INTERFACES">EC: Call to equals() comparing different interface types (EC_UNRELATED_INTERFACES)</a></h3>
1439
1440
1441 <p> This method calls equals(Object) on two references of unrelated
1442 interface types, where neither is a subtype of the other,
1443 and there are no known non-abstract classes which implement both interfaces.
1444 Therefore, the objects being compared
1445 are unlikely to be members of the same class at runtime
1446 (unless some application classes were not analyzed, or dynamic class
1447 loading can occur at runtime).
1448 According to the contract of equals(),
1449 objects of different
1450 classes should always compare as unequal; therefore, according to the
1451 contract defined by java.lang.Object.equals(Object),
1452 the result of this comparison will always be false at runtime.
1453 </p>
1454
1455
1456 <h3><a name="EC_UNRELATED_TYPES">EC: Call to equals() comparing different types (EC_UNRELATED_TYPES)</a></h3>
1457
1458
1459 <p> This method calls equals(Object) on two references of different
1460 class types with no common subclasses.
1461 Therefore, the objects being compared
1462 are unlikely to be members of the same class at runtime
1463 (unless some application classes were not analyzed, or dynamic class
1464 loading can occur at runtime).
1465 According to the contract of equals(),
1466 objects of different
1467 classes should always compare as unequal; therefore, according to the
1468 contract defined by java.lang.Object.equals(Object),
1469 the result of this comparison will always be false at runtime.
1470 </p>
1471
1472
1473 <h3><a name="EC_UNRELATED_TYPES_USING_POINTER_EQUALITY">EC: Using pointer equality  to compare  different types (EC_UNRELATED_TYPES_USING_POINTER_EQUALITY)</a></h3>
1474
1475
1476 <p> This method uses using pointer equality to compare two references that seem to be of
1477 different types.  The result of this comparison will always be false at runtime.
1478 </p>
1479
1480
1481 <h3><a name="EQ_DONT_DEFINE_EQUALS_FOR_ENUM">Eq: Covariant equals() method defined for enum (EQ_DONT_DEFINE_EQUALS_FOR_ENUM)</a></h3>
1482
1483
1484   <p> This class defines an enumeration, and equality on enumerations are defined
1485 using object identity. Definine a covariant equals method for an enumeration
1486 value is exceptionally bad practice, since it would likely result
1487 in having two different enumeration values that compare as equals using
1488 the covariant enum method, and as not equal when compared normally.
1489 Don't do it.
1490 </p>
1491
1492
1493 <h3><a name="EQ_OVERRIDING_EQUALS_NOT_SYMMETRIC">Eq: equals method overrides equals in superclass and may not be symmetric (EQ_OVERRIDING_EQUALS_NOT_SYMMETRIC)</a></h3>
1494
1495
1496   <p> This class defines an equals method that overrides an equals method in a superclass. Both equals methods
1497 methods use <code>instanceof</code> in the determination of whether two objects are equals. This is fraught with peril,
1498 since it is important that the equals method is symetrical (in other words, <code>a.equals(b) == b.equals(a)</code>).
1499 If B is a subtype of A, and A's equals method checks that the argument is an instanceof A, and B's equals method
1500 checks that the argument is an instanceof B, it is quite likely that the equivalence relation defined by these
1501 methods is not symmetric.
1502
1503
1504 <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>
1505
1506
1507     <p>
1508     This code checks to see if a floating point value is equal to the special
1509         Not A Number value (e.g., <code>if (x == Double.NaN)</code>). However,
1510         because of the special semantics of <code>NaN</code>, no value
1511         is equal to <code>Nan</code>, including <code>NaN</code>. Thus,
1512         <code>x == Double.NaN</code> always evaluates to false.
1513
1514         To check to see if a value contained in <code>x</code>
1515         is the special Not A Number value, use
1516         <code>Double.isNaN(x)</code> (or <code>Float.isNaN(x)</code> if
1517         <code>x</code> is floating point precision).
1518     </p>
1519
1520
1521 <h3><a name="GC_UNRELATED_TYPES">GC: No relationship between generic parameter and method argument (GC_UNRELATED_TYPES)</a></h3>
1522
1523
1524      <p> This call to a generic container's method contains an argument
1525      with a different class type from that of the container's parameter.
1526      Therefore, it is unlikely that the container contains any objects
1527      with the same type as the method argument used here.
1528      </p>
1529
1530
1531 <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>
1532
1533
1534   <p> A class defines an equals(Object)  method but not a hashCode() method,
1535 and thus doesn't fulfill the requirement that equal Objects have equal hashCodes.
1536 An instance of this class is used in a hash data structure, making the need to
1537 fix this problem of highest importance.
1538
1539
1540 <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>
1541
1542
1543 <p>
1544 The code performs an integer shift by a constant amount outside
1545 the range 0..31.
1546 The effect of this is to use the lower 5 bits of the integer
1547 value to decide how much to shift by. This probably isn't want was expected,
1548 and it at least confusing.
1549 </p>
1550
1551
1552 <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>
1553
1554
1555 <p>
1556 This code converts an int value to a double precision
1557 floating point number and then
1558 passing the result to the Math.ceil() function, which rounds a double to
1559 the next higher integer value. This operation should always be a no-op,
1560 since the converting an integer to a double should give a number with no fractional part.
1561 It is likely that the operation that generated the value to be passed
1562 to Math.ceil was intended to be performed using double precision
1563 floating point arithmetic.
1564 </p>
1565
1566
1567
1568 <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>
1569
1570
1571 <p>
1572 This code converts an int value to a float precision
1573 floating point number and then
1574 passing the result to the Math.round() function, which returns the int/long closest
1575 to the argument. This operation should always be a no-op,
1576 since the converting an integer to a float should give a number with no fractional part.
1577 It is likely that the operation that generated the value to be passed
1578 to Math.round was intended to be performed using
1579 floating point arithmetic.
1580 </p>
1581
1582
1583
1584 <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>
1585
1586
1587 <p> A JUnit assertion is performed in a run method. Failed JUnit assertions
1588 just result in exceptions being thrown.
1589 Thus, if this exception occurs in a thread other than the thread that invokes
1590 the test method, the exception will terminate the thread but not result
1591 in the test failing.
1592 </p>
1593
1594
1595 <h3><a name="IJU_BAD_SUITE_METHOD">IJU: TestCase declares a bad suite method  (IJU_BAD_SUITE_METHOD)</a></h3>
1596
1597
1598 <p> Class is a JUnit TestCase and defines a suite() method.
1599 However, the suite method needs to be declared as either
1600 <pre>public static junit.framework.Test suite()</pre>
1601 or
1602 <pre>public static junit.framework.TestSuite suite()</pre>
1603 </p>
1604
1605
1606 <h3><a name="IJU_NO_TESTS">IJU: TestCase has no tests (IJU_NO_TESTS)</a></h3>
1607
1608
1609 <p> Class is a JUnit TestCase but has not implemented any test methods</p>
1610
1611
1612 <h3><a name="IJU_SETUP_NO_SUPER">IJU: TestCase implements setUp but doesn't call super.setUp() (IJU_SETUP_NO_SUPER)</a></h3>
1613
1614
1615 <p> Class is a JUnit TestCase and implements the setUp method. The setUp method should call
1616 super.setUp(), but doesn't.</p>
1617
1618
1619 <h3><a name="IJU_SUITE_NOT_STATIC">IJU: TestCase implements a non-static suite method  (IJU_SUITE_NOT_STATIC)</a></h3>
1620
1621
1622 <p> Class is a JUnit TestCase and implements the suite() method.
1623  The suite method should be declared as being static, but isn't.</p>
1624
1625
1626 <h3><a name="IJU_TEARDOWN_NO_SUPER">IJU: TestCase implements tearDown but doesn't call super.tearDown() (IJU_TEARDOWN_NO_SUPER)</a></h3>
1627
1628
1629 <p> Class is a JUnit TestCase and implements the tearDown method. The tearDown method should call
1630 super.tearDown(), but doesn't.</p>
1631
1632
1633 <h3><a name="IL_CONTAINER_ADDED_TO_ITSELF">IL: A container is added to itself (IL_CONTAINER_ADDED_TO_ITSELF)</a></h3>
1634
1635
1636 <p>A container is added to itself. As a result, computing the hashCode of this
1637 set will throw a StackOverflowException.
1638 </p>
1639
1640
1641 <h3><a name="IL_INFINITE_LOOP">IL: An apparent infinite loop (IL_INFINITE_LOOP)</a></h3>
1642
1643
1644 <p>This loop doesn't seem to have a way to terminate (other than by perhaps
1645 throwing an exception).</p>
1646
1647
1648 <h3><a name="IL_INFINITE_RECURSIVE_LOOP">IL: An apparent infinite recursive loop (IL_INFINITE_RECURSIVE_LOOP)</a></h3>
1649
1650
1651 <p>This method unconditionally invokes itself. This would seem to indicate
1652 an infinite recursive loop that will result in a stack overflow.</p>
1653
1654
1655 <h3><a name="IM_MULTIPLYING_RESULT_OF_IREM">IM: Integer multiply of result of integer remainder (IM_MULTIPLYING_RESULT_OF_IREM)</a></h3>
1656
1657
1658 <p>
1659 The code multiplies the result of an integer remaining by an integer constant.
1660 Be sure you don't have your operator precedence confused. For example
1661 i % 60 * 1000 is (i % 60) * 1000, not i % (60 * 1000).
1662 </p>
1663
1664
1665 <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>
1666
1667
1668 <p> This code compares a value that is guaranteed to be non-negative with a negative constant.
1669 </p>
1670
1671
1672 <h3><a name="INT_BAD_COMPARISON_WITH_SIGNED_BYTE">INT: Bad comparison of signed byte (INT_BAD_COMPARISON_WITH_SIGNED_BYTE)</a></h3>
1673
1674
1675 <p> Signed bytes can only have a value in the range -128 to 127. Comparing
1676 a signed byte with a value outside that range is vacuous and likely to be incorrect.
1677 To convert a signed byte <code>b</code> to an unsigned value in the range 0..255,
1678 use <code>0xff & b</code>
1679 </p>
1680
1681
1682 <h3><a name="INT_BAD_REM_BY_1">INT: Integer remainder modulo 1 (INT_BAD_REM_BY_1)</a></h3>
1683
1684
1685 <p> Any expression (exp % 1) is guaranteed to always return zero.
1686 Did you mean (exp & 1) or (exp % 2) instead?
1687 </p>
1688
1689
1690 <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>
1691
1692
1693 <p>
1694 The initial value of this parameter is ignored, and the parameter
1695 is overwritten here. This often indicates a mistaken belief that
1696 the write to the parameter will be conveyed back to
1697 the caller.
1698 </p>
1699
1700
1701 <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>
1702
1703
1704   <p> The class is annotated with net.jcip.annotations.Immutable, and the rules for that annotation require
1705 that all fields are final.
1706    .</p>
1707
1708
1709 <h3><a name="MF_CLASS_MASKS_FIELD">MF: Class defines field that masks a superclass field (MF_CLASS_MASKS_FIELD)</a></h3>
1710
1711
1712 <p> This class defines a field with the same name as a visible
1713 instance field in a superclass.  This is confusing, and
1714 may indicate an error if methods update or access one of
1715 the fields when they wanted the other.</p>
1716
1717
1718 <h3><a name="MF_METHOD_MASKS_FIELD">MF: Method defines a variable that obscures a field (MF_METHOD_MASKS_FIELD)</a></h3>
1719
1720
1721 <p> This method defines a local variable with the same name as a field
1722 in this class or a superclass.  This may cause the method to
1723 read an uninitialized value from the field, leave the field uninitialized,
1724 or both.</p>
1725
1726
1727 <h3><a name="NP_ALWAYS_NULL">NP: Null pointer dereference (NP_ALWAYS_NULL)</a></h3>
1728
1729
1730 <p> A null pointer is dereferenced here.&nbsp; This will lead to a
1731 <code>NullPointerException</code> when the code is executed.</p>
1732
1733
1734 <h3><a name="NP_ALWAYS_NULL_EXCEPTION">NP: Null pointer dereference in method on exception path (NP_ALWAYS_NULL_EXCEPTION)</a></h3>
1735
1736
1737 <p> A pointer which is null on an exception path is dereferenced here.&nbsp;
1738 This will lead to a <code>NullPointerException</code> when the code is executed.&nbsp;
1739 Note that because FindBugs currently does not prune infeasible exception paths,
1740 this may be a false warning.</p>
1741
1742 <p> Also note that FindBugs considers the default case of a switch statement to
1743 be an exception path, since the default case is often infeasible.</p>
1744
1745
1746 <h3><a name="NP_ARGUMENT_MIGHT_BE_NULL">NP: Method does not check for null argument (NP_ARGUMENT_MIGHT_BE_NULL)</a></h3>
1747
1748
1749       <p>
1750         A parameter to this method has been identified as a value that should
1751         always be checked to see whether or not it is null, but it is being dereferenced
1752         without a preceding null check.
1753       </p>
1754
1755
1756 <h3><a name="NP_GUARANTEED_DEREF">NP: Null value is guaranteed to be dereferenced (NP_GUARANTEED_DEREF)</a></h3>
1757
1758
1759                           <p>
1760                           There is a statement or branch that if executed guarantees that
1761                           a value is null at this point, and that
1762                           value that is guaranteed to be dereferenced
1763                           (except on forward paths involving runtime exceptions).
1764                           </p>
1765
1766
1767 <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>
1768
1769
1770                           <p>
1771                           There is a statement or branch on an exception path
1772                                 that if executed guarantees that
1773                           a value is null at this point, and that
1774                           value that is guaranteed to be dereferenced
1775                           (except on forward paths involving runtime exceptions).
1776                           </p>
1777
1778
1779 <h3><a name="NP_NONNULL_PARAM_VIOLATION">NP: Method call passes null to a nonnull parameter  (NP_NONNULL_PARAM_VIOLATION)</a></h3>
1780
1781
1782       <p>
1783       This method passes a null value as the parameter of a method which
1784         must be nonnull. Either this parameter has been explicitly marked
1785         as @Nonnull, or analysis has determined that this parameter is
1786         always dereferenced.
1787       </p>
1788
1789
1790 <h3><a name="NP_NONNULL_RETURN_VIOLATION">NP: Method may return null, but is declared @NonNull (NP_NONNULL_RETURN_VIOLATION)</a></h3>
1791
1792
1793       <p>
1794       This method may return a null value, but the method (or a superclass method
1795       which it overrides) is declared to return @NonNull.
1796       </p>
1797
1798
1799 <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>
1800
1801
1802 <p>
1803 This instanceof test will always return false, since the value being checked is guaranteed to be null.
1804 Although this is safe, make sure it isn't
1805 an indication of some misunderstanding or some other logic error.
1806 </p>
1807
1808
1809 <h3><a name="NP_NULL_ON_SOME_PATH">NP: Possible null pointer dereference (NP_NULL_ON_SOME_PATH)</a></h3>
1810
1811
1812 <p> A reference value dereferenced here might be null at runtime.&nbsp;
1813 This may lead to a <code>NullPointerException</code> when the code is executed.</p>
1814
1815
1816 <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>
1817
1818
1819 <p> A reference value which is null on some exception control path is
1820 dereferenced here.&nbsp; This may lead to a <code>NullPointerException</code>
1821 when the code is executed.&nbsp;
1822 Note that because FindBugs currently does not prune infeasible exception paths,
1823 this may be a false warning.</p>
1824
1825 <p> Also note that FindBugs considers the default case of a switch statement to
1826 be an exception path, since the default case is often infeasible.</p>
1827
1828
1829 <h3><a name="NP_NULL_PARAM_DEREF">NP: Method call passes null for unconditionally dereferenced parameter (NP_NULL_PARAM_DEREF)</a></h3>
1830
1831
1832       <p>
1833       This method call passes a null value to a method which might
1834       dereference it unconditionally.
1835       </p>
1836
1837
1838 <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>
1839
1840
1841       <p>
1842       A possibly-null value is passed at a call site where all known
1843       target methods will unconditionally dereference it.
1844       This is very likely to result in a null pointer exception.
1845       </p>
1846
1847
1848 <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>
1849
1850
1851       <p>
1852       A possibly-null value is passed to a method which unconditionally
1853       dereferences it.  This will almost certainly result in a null pointer exception.
1854       </p>
1855
1856
1857 <h3><a name="NP_STORE_INTO_NONNULL_FIELD">NP: Store of null value into field annotated NonNull (NP_STORE_INTO_NONNULL_FIELD)</a></h3>
1858
1859
1860 <p> A value that could be null is stored into a field that has been annotated as NonNull. </p>
1861
1862
1863 <h3><a name="NP_UNWRITTEN_FIELD">NP: Read of unwritten field (NP_UNWRITTEN_FIELD)</a></h3>
1864
1865
1866   <p> The program is dereferencing a field that does not seem to ever have a non-null value written to it.
1867 Dereferencing this value will generate a null pointer exception.
1868 </p>
1869
1870
1871 <h3><a name="NM_BAD_EQUAL">Nm: Class defines equal(); should it be equals()? (NM_BAD_EQUAL)</a></h3>
1872
1873
1874 <p> This class defines a method <code>equal(Object)</code>.&nbsp; This method does
1875 not override the <code>equals(Object)</code> method in <code>java.lang.Object</code>,
1876 which is probably what was intended.</p>
1877
1878
1879 <h3><a name="NM_LCASE_HASHCODE">Nm: Class defines hashcode(); should it be hashCode()? (NM_LCASE_HASHCODE)</a></h3>
1880
1881
1882   <p> This class defines a method called <code>hashcode()</code>.&nbsp; This method
1883   does not override the <code>hashCode()</code> method in <code>java.lang.Object</code>,
1884   which is probably what was intended.</p>
1885
1886
1887 <h3><a name="NM_LCASE_TOSTRING">Nm: Class defines tostring(); should it be toString()? (NM_LCASE_TOSTRING)</a></h3>
1888
1889
1890   <p> This class defines a method called <code>tostring()</code>.&nbsp; This method
1891   does not override the <code>toString()</code> method in <code>java.lang.Object</code>,
1892   which is probably what was intended.</p>
1893
1894
1895 <h3><a name="NM_METHOD_CONSTRUCTOR_CONFUSION">Nm: Apparent method/constructor confusion (NM_METHOD_CONSTRUCTOR_CONFUSION)</a></h3>
1896
1897
1898   <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.
1899       If it was intended to be a constructor, remove the declaration of a void return value.
1900         If you had accidently defined this method, realized the mistake, defined a proper constructor
1901         but can't get rid of this method due to backwards compatibility, deprecate the method.
1902 </p>
1903
1904
1905 <h3><a name="NM_VERY_CONFUSING">Nm: Very confusing method names (NM_VERY_CONFUSING)</a></h3>
1906
1907
1908   <p> The referenced methods have names that differ only by capitalization.
1909 This is very confusing because if the capitalization were
1910 identical then one of the methods would override the other.
1911 </p>
1912
1913
1914 <h3><a name="NM_WRONG_PACKAGE">Nm: Method doesn't override method in superclass due to wrong package for parameter (NM_WRONG_PACKAGE)</a></h3>
1915
1916
1917   <p> The method in the subclass doesn't override a similar method in a superclass because the type of a parameter doesn't exactly match
1918 the type of the corresponding parameter in the superclass. For example, if you have:</p>
1919
1920 <blockquote>
1921 <pre>
1922 import alpha.Foo;
1923 public class A {
1924   public int f(Foo x) { return 17; }
1925 }
1926 ----
1927 import beta.Foo;
1928 public class B extends A {
1929   public int f(Foo x) { return 42; }
1930 }
1931 </pre>
1932 </blockquote>
1933
1934 <p>The <code>f(Foo)</code> method defined in class <code>B</code> doesn't
1935 override the
1936 <code>f(Foo)</code> method defined in class <code>A</code>, because the argument
1937 types are <code>Foo</code>'s from different packages.
1938 </p>
1939
1940
1941 <h3><a name="QBA_QUESTIONABLE_BOOLEAN_ASSIGNMENT">QBA: Method assigns boolean literal in boolean expression (QBA_QUESTIONABLE_BOOLEAN_ASSIGNMENT)</a></h3>
1942
1943
1944       <p>
1945       This method assigns a literal boolean value (true or false) to a boolean variable inside
1946       an if or while expression. Most probably this was supposed to be a boolean comparison using
1947       ==, not an assignment using =.
1948       </p>
1949
1950
1951 <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>
1952
1953
1954 <p> A value is checked here to see whether it is null, but this value can't
1955 be null because it was previously dereferenced and if it were null a null pointer
1956 exception would have occurred at the earlier dereference.
1957 Essentially, this code and the previous dereference
1958 disagree as to whether this value is allowed to be null. Either the check is redundant
1959 or the previous dereference is erroneous.</p>
1960
1961
1962 <h3><a name="RE_BAD_SYNTAX_FOR_REGULAR_EXPRESSION">RE: Invalid syntax for regular expression (RE_BAD_SYNTAX_FOR_REGULAR_EXPRESSION)</a></h3>
1963
1964
1965 <p>
1966 The code here uses a regular expression that is invalid according to the syntax
1967 for regular expressions. This statement will throw a PatternSyntaxException when
1968 executed.
1969 </p>
1970
1971
1972 <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>
1973
1974
1975 <p>
1976 The code here uses <code>File.separator</code>
1977 where a regular expression is required. This will fail on Windows
1978 platforms, where the  <code>File.separator</code> is a backslash, which is interpreted in a
1979 regular expression as an escape character. Amoung other options, you can just use
1980 <code>File.separatorChar=='\\' &amp; "\\\\" : File.separator</code> instead of
1981 <code>File.separator</code>
1982
1983 </p>
1984
1985
1986 <h3><a name="RE_POSSIBLE_UNINTENDED_PATTERN">RE: "." used for regular expression (RE_POSSIBLE_UNINTENDED_PATTERN)</a></h3>
1987
1988
1989 <p>
1990 A String function is being invoked and "." is being passed
1991 to a parameter that takes a regular expression as an argument. Is this what you intended?
1992 For example
1993 s.replaceAll(".", "/") will return a String in which <em>every</em>
1994 character has been replaced by a / character.
1995 </p>
1996
1997
1998 <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>
1999
2000
2001   <p>A random value from 0 to 1 is being coerced to the integer value 0. You probably
2002 want to multiple the random value by something else before coercing it to an integer, or use the Random.nextInt(n) method.
2003 </p>
2004
2005
2006 <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>
2007
2008
2009 <p> This code generates a hashcode and then computes
2010 the absolute value of that hashcode.  If the hashcode
2011 is <code>Integer.MIN_VALUE</code>, then the result will be negative as well (since
2012 <code>Math.abs(Integer.MIN_VALUE) == Integer.MIN_VALUE</code>).
2013 </p>
2014
2015
2016 <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>
2017
2018
2019 <p> This code generates a random signed integer and then computes
2020 the absolute value of that random integer.  If the number returned by the random number
2021 generator is <code>Integer.MIN_VALUE</code>, then the result will be negative as well (since
2022 <code>Math.abs(Integer.MIN_VALUE) == Integer.MIN_VALUE</code>).
2023 </p>
2024
2025
2026 <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>
2027
2028
2029    <p> The value returned by readLine is discarded after checking to see if the return
2030 value is non-null. In almost all situations, if the result is non-null, you will want
2031 to use that non-null value. Calling readLine again will give you a different line.</p>
2032
2033
2034 <h3><a name="RV_EXCEPTION_NOT_THROWN">RV: Exception created and dropped rather than thrown (RV_EXCEPTION_NOT_THROWN)</a></h3>
2035
2036
2037    <p> This code creates an exception (or error) object, but doesn't do anything with it. For example,
2038 something like  </p>
2039 <blockquote>
2040 <pre>
2041 if (x < 0)
2042   new IllegalArgumentException("x must be nonnegative");
2043 </pre>
2044 </blockquote>
2045 <p>It was probably the intent of the programmer to throw the created exception:</p>
2046 <blockquote>
2047 <pre>
2048 if (x < 0)
2049   throw new IllegalArgumentException("x must be nonnegative");
2050 </pre>
2051 </blockquote>
2052
2053
2054 <h3><a name="RV_RETURN_VALUE_IGNORED">RV: Method ignores return value (RV_RETURN_VALUE_IGNORED)</a></h3>
2055
2056
2057    <p> The return value of this method should be checked. One common
2058 cause of this warning is to invoke a method on an immutable object,
2059 thinking that it updates the object. For example, in the following code
2060 fragment,</p>
2061 <blockquote>
2062 <pre>
2063 String dateString = getHeaderField(name);
2064 dateString.trim();
2065 </pre>
2066 </blockquote>
2067 <p>the programmer seems to be thinking that the trim() method will update
2068 the String referenced by dateString. But since Strings are immutable, the trim()
2069 function returns a new String value, which is being ignored here. The code
2070 should be corrected to: </p>
2071 <blockquote>
2072 <pre>
2073 String dateString = getHeaderField(name);
2074 dateString = dateString.trim();
2075 </pre>
2076 </blockquote>
2077
2078
2079 <h3><a name="SA_FIELD_DOUBLE_ASSIGNMENT">SA: Double assignment of field (SA_FIELD_DOUBLE_ASSIGNMENT)</a></h3>
2080
2081
2082 <p> This method contains a double assignment of a field; e.g.
2083 </p>
2084 <pre>
2085   int x,y;
2086   public void foo() {
2087     x = x = 17;
2088   }
2089 </pre>
2090 <p>Assigning to a field twice is useless, and may indicate a logic error or typo.</p>
2091
2092
2093 <h3><a name="SA_FIELD_SELF_ASSIGNMENT">SA: Self assignment of field (SA_FIELD_SELF_ASSIGNMENT)</a></h3>
2094
2095
2096 <p> This method contains a self assignment of a field; e.g.
2097 </p>
2098 <pre>
2099   int x;
2100   public void foo() {
2101     x = x;
2102   }
2103 </pre>
2104 <p>Such assignments are useless, and may indicate a logic error or typo.</p>
2105
2106
2107 <h3><a name="SA_FIELD_SELF_COMPARISON">SA: Self comparison of field with itself (SA_FIELD_SELF_COMPARISON)</a></h3>
2108
2109
2110 <p> This method compares a field with itself, and may indicate a typo or
2111 a logic error.  Make sure that you are comparing the right things.
2112 </p>
2113
2114
2115 <h3><a name="SA_FIELD_SELF_COMPUTATION">SA: Nonsensical self computation involving a field (e.g., x & x) (SA_FIELD_SELF_COMPUTATION)</a></h3>
2116
2117
2118 <p> This method performs a nonsensical computation of a field with another
2119 reference to the same field (e.g., x&x or x-x). Because of the nature
2120 of the computation, this operation doesn't seem to make sense,
2121 and may indicate a typo or
2122 a logic error.  Double check the computation.
2123 </p>
2124
2125
2126 <h3><a name="SA_LOCAL_DOUBLE_ASSIGNMENT">SA: Double assignment of local variable  (SA_LOCAL_DOUBLE_ASSIGNMENT)</a></h3>
2127
2128
2129 <p> This method contains a double assignment of a local variable; e.g.
2130 </p>
2131 <pre>
2132   public void foo() {
2133     int x,y;
2134     x = x = 17;
2135   }
2136 </pre>
2137 <p>Assigning the same value to  a variable twice is useless, and may indicate a logic error or typo.</p>
2138
2139
2140 <h3><a name="SA_LOCAL_SELF_COMPARISON">SA: Self comparison of value with itself (SA_LOCAL_SELF_COMPARISON)</a></h3>
2141
2142
2143 <p> This method compares a local variable with itself, and may indicate a typo or
2144 a logic error.  Make sure that you are comparing the right things.
2145 </p>
2146
2147
2148 <h3><a name="SA_LOCAL_SELF_COMPUTATION">SA: Nonsensical self computation involving a variable (e.g., x & x) (SA_LOCAL_SELF_COMPUTATION)</a></h3>
2149
2150
2151 <p> This method performs a nonsensical computation of a local variable with another
2152 reference to the same variable (e.g., x&x or x-x). Because of the nature
2153 of the computation, this operation doesn't seem to make sense,
2154 and may indicate a typo or
2155 a logic error.  Double check the computation.
2156 </p>
2157
2158
2159 <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>
2160
2161
2162   <p> A value stored in the previous switch case is overwritten here due to a switch fall through. It is likely that
2163         you forgot to put a break or return at the end of the previous case.
2164 </p>
2165
2166
2167 <h3><a name="SIO_SUPERFLUOUS_INSTANCEOF">SIO: Unnecessary type check done using instanceof operator (SIO_SUPERFLUOUS_INSTANCEOF)</a></h3>
2168
2169
2170 <p> Type check performed using the instanceof operator where it can be statically determined whether the object
2171 is of the type requested. </p>
2172
2173
2174 <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>
2175
2176
2177 <p> A call to a setXXX method of a prepared statement was made where the
2178 parameter index is 0. As parameter indexes start at index 1, this is always a mistake.</p>
2179
2180
2181 <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>
2182
2183
2184 <p> A call to getXXX or updateXXX methods of a result set was made where the
2185 field index is 0. As ResultSet fields start at index 1, this is always a mistake.</p>
2186
2187
2188 <h3><a name="STI_INTERRUPTED_ON_CURRENTTHREAD">STI: Unneeded use of currentThread() call, to call interrupted()  (STI_INTERRUPTED_ON_CURRENTTHREAD)</a></h3>
2189
2190
2191 <p>
2192 This method invokes the Thread.currentThread() call, just to call the interrupted() method. As interrupted() is a
2193 static method, is more simple and clear to use Thread.interrupted().
2194 </p>
2195
2196
2197 <h3><a name="STI_INTERRUPTED_ON_UNKNOWNTHREAD">STI: Static Thread.interrupted() method invoked on thread instance (STI_INTERRUPTED_ON_UNKNOWNTHREAD)</a></h3>
2198
2199
2200 <p>
2201 This method invokes the Thread.interrupted() method on a Thread object that appears to be a Thread object that is
2202 not the current thread. As the interrupted() method is static, the interrupted method will be called on a different
2203 object than the one the author intended.
2204 </p>
2205
2206
2207 <h3><a name="TQ_ALWAYS_VALUE_USED_WHERE_NEVER_REQUIRED">TQ: Value annotated as carrying a type qualifier used where a value that must not carry that qualifier is required (TQ_ALWAYS_VALUE_USED_WHERE_NEVER_REQUIRED)</a></h3>
2208
2209
2210         <p>
2211         A value specified as carrying a type qualifier annotation is
2212         consumed in a location or locations requiring that the value not
2213         carry that annotation.
2214         </p>
2215
2216         <p>
2217         More precisely, a value annotated with a type qualifier specifying when=ALWAYS
2218         is guaranteed to reach a use or uses where the same type qualifier specifies when=NEVER.
2219         </p>
2220
2221         <p>
2222         For example, say that @NonNegative is a nickname for
2223         the type qualifier annotation @Negative(when=When.NEVER).
2224         The following code will generate this warning because
2225         the return statement requires a @NonNegative value,
2226         but receives one that is marked as @Negative.
2227         </p>
2228         <blockquote>
2229 <pre>
2230 public @NonNegative Integer example(@Negative Integer value) {
2231     return value;
2232 }
2233 </pre>
2234         </blockquote>
2235
2236
2237 <h3><a name="TQ_MAYBE_SOURCE_VALUE_REACHES_ALWAYS_SINK">TQ: Value that might not carry a type qualifier reaches a use requiring that type qualifier (TQ_MAYBE_SOURCE_VALUE_REACHES_ALWAYS_SINK)</a></h3>
2238
2239
2240       <p>
2241       A value that might not carry a type qualifier annotation
2242       reaches a use which requires that annotation.
2243       </p>
2244
2245       <p>
2246       For example, consider the following method:
2247       </p>
2248       <blockquote>
2249 <pre>
2250 public @Untainted Object mustReturnUntainted(Object unknown) {
2251     return unknown;
2252 }
2253 </pre>
2254       </blockquote>
2255       <p>
2256       The <code>mustReturnUntainted</code> method is required to
2257       return a value carrying the @Untainted annotation,
2258       but a value not known to carry that annotation is returned.
2259       </p>
2260
2261
2262 <h3><a name="TQ_MAYBE_SOURCE_VALUE_REACHES_NEVER_SINK">TQ: Unknown value reaches a use which forbids values carrying type qualifier annotation (TQ_MAYBE_SOURCE_VALUE_REACHES_NEVER_SINK)</a></h3>
2263
2264
2265       <p>
2266       A value which might carry a type qualifier annotation reaches
2267       a use which forbids values carrying that annotation.
2268       </p>
2269
2270       <p>
2271       TODO: example.
2272       </p>
2273
2274
2275 <h3><a name="TQ_NEVER_VALUE_USED_WHERE_ALWAYS_REQUIRED">TQ: Value annotated as never carrying a type qualifier used where value carrying that qualifier is required (TQ_NEVER_VALUE_USED_WHERE_ALWAYS_REQUIRED)</a></h3>
2276
2277
2278         <p>
2279         A value specified as not carrying a type qualifier annotation is guaranteed
2280         to be consumed in a location or locations requiring that the value does
2281         carry that annotation.
2282         </p>
2283
2284         <p>
2285         More precisely, a value annotated with a type qualifier specifying when=NEVER
2286         is guaranteed to reach a use or uses where the same type qualifier specifies when=ALWAYS.
2287         </p>
2288
2289         <p>
2290         TODO: example
2291         </p>
2292
2293
2294 <h3><a name="UCF_USELESS_CONTROL_FLOW_NEXT_LINE">UCF: Useless control flow to next line (UCF_USELESS_CONTROL_FLOW_NEXT_LINE)</a></h3>
2295
2296
2297 <p> This method contains a useless control flow statement in which control
2298 flow follows to the same or following line regardless of whether or not
2299 the branch is taken.
2300 Often, this is caused by inadvertently using an empty statement as the
2301 body of an <code>if</code> statement, e.g.:</p>
2302 <pre>
2303     if (argv.length == 1);
2304         System.out.println("Hello, " + argv[0]);
2305 </pre>
2306
2307
2308 <h3><a name="UMAC_UNCALLABLE_METHOD_OF_ANONYMOUS_CLASS">UMAC: Uncallable method defined in anonymous class (UMAC_UNCALLABLE_METHOD_OF_ANONYMOUS_CLASS)</a></h3>
2309
2310
2311 <p> This anonymous class defined a method that is not directly invoked and does not override
2312 a method in a superclass. Since methods in other classes cannot directly invoke methods
2313 declared in an anonymous class, it seems that this method is uncallable. The method
2314 might simply be dead code, but it is also possible that the method is intended to
2315 override a method declared in a superclass, and due to an typo or other error the method does not,
2316 in fact, override the method it is intended to.
2317 </p>
2318
2319
2320 <h3><a name="UR_UNINIT_READ">UR: Uninitialized read of field in constructor (UR_UNINIT_READ)</a></h3>
2321
2322
2323   <p> This constructor reads a field which has not yet been assigned a value.&nbsp;
2324   This is often caused when the programmer mistakenly uses the field instead
2325   of one of the constructor's parameters.</p>
2326
2327
2328 <h3><a name="UWF_NULL_FIELD">UwF: Field only ever set to null (UWF_NULL_FIELD)</a></h3>
2329
2330
2331   <p> All writes to this field are of the constant value null, and thus
2332 all reads of the field will return null.
2333 Check for errors, or remove it if it is useless.</p>
2334
2335
2336 <h3><a name="UWF_UNWRITTEN_FIELD">UwF: Unwritten field (UWF_UNWRITTEN_FIELD)</a></h3>
2337
2338
2339   <p> This field is never written.&nbsp; All reads of it will return the default
2340 value. Check for errors (should it have been initialized?), or remove it if it is useless.</p>
2341
2342
2343 <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>
2344
2345
2346 <p>
2347 This code passes a primitive array to a function that takes a variable number of object arguments.
2348 This creates an array of length one to hold the primitive array and passes it to the function.
2349 </p>
2350
2351
2352 <h3><a name="DM_CONVERT_CASE">Dm: Consider using Locale parameterized version of invoked method (DM_CONVERT_CASE)</a></h3>
2353
2354
2355   <p> A String is being converted to upper or lowercase, using the platform's default encoding. This may
2356       result in improper conversions when used with international characters. Use the </p>
2357       <table><tr><td>String.toUpperCase( Locale l )</td></tr><tr><td>String.toLowerCase( Locale l )</td></tr></table>
2358       <p>versions instead.</p>
2359
2360
2361 <h3><a name="EI_EXPOSE_REP">EI: May expose internal representation by returning reference to mutable object (EI_EXPOSE_REP)</a></h3>
2362
2363
2364   <p> Returning a reference to a mutable object value stored in one of the object's fields
2365   exposes the internal representation of the object.&nbsp;
2366    If instances
2367    are accessed by untrusted code, and unchecked changes to
2368    the mutable object would compromise security or other
2369    important properties, you will need to do something different.
2370   Returning a new copy of the object is better approach in many situations.</p>
2371
2372
2373 <h3><a name="EI_EXPOSE_REP2">EI2: May expose internal representation by incorporating reference to mutable object (EI_EXPOSE_REP2)</a></h3>
2374
2375
2376   <p> This code stores a reference to an externally mutable object into the
2377   internal representation of the object.&nbsp;
2378    If instances
2379    are accessed by untrusted code, and unchecked changes to
2380    the mutable object would compromise security or other
2381    important properties, you will need to do something different.
2382   Storing a copy of the object is better approach in many situations.</p>
2383
2384
2385 <h3><a name="FI_PUBLIC_SHOULD_BE_PROTECTED">FI: Finalizer should be protected, not public (FI_PUBLIC_SHOULD_BE_PROTECTED)</a></h3>
2386
2387
2388   <p> A class's <code>finalize()</code> method should have protected access,
2389    not public.</p>
2390
2391
2392 <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>
2393
2394
2395   <p> This code stores a reference to an externally mutable object into a static
2396    field.
2397    If unchecked changes to
2398    the mutable object would compromise security or other
2399    important properties, you will need to do something different.
2400   Storing a copy of the object is better approach in many situations.</p>
2401
2402
2403 <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>
2404
2405
2406   <p>
2407  A mutable static field could be changed by malicious code or
2408         by accident from another package.
2409    Unfortunately, the way the field is used doesn't allow
2410    any easy fix to this problem.</p>
2411
2412
2413 <h3><a name="MS_EXPOSE_REP">MS: Public static method may expose internal representation by returning array (MS_EXPOSE_REP)</a></h3>
2414
2415
2416   <p> A public static method returns a reference to
2417    an array that is part of the static state of the class.
2418    Any code that calls this method can freely modify
2419    the underlying array.
2420    One fix is to return a copy of the array.</p>
2421
2422
2423 <h3><a name="MS_FINAL_PKGPROTECT">MS: Field should be both final and package protected (MS_FINAL_PKGPROTECT)</a></h3>
2424
2425
2426  <p>
2427    A mutable static field could be changed by malicious code or
2428         by accident from another package.
2429         The field could be made package protected and/or made final
2430    to avoid
2431         this vulnerability.</p>
2432
2433
2434 <h3><a name="MS_MUTABLE_ARRAY">MS: Field is a mutable array (MS_MUTABLE_ARRAY)</a></h3>
2435
2436
2437 <p> A final static field references an array
2438    and can be accessed by malicious code or
2439         by accident from another package.
2440    This code can freely modify the contents of the array.</p>
2441
2442
2443 <h3><a name="MS_MUTABLE_HASHTABLE">MS: Field is a mutable Hashtable (MS_MUTABLE_HASHTABLE)</a></h3>
2444
2445
2446  <p>A final static field references a Hashtable
2447    and can be accessed by malicious code or
2448         by accident from another package.
2449    This code can freely modify the contents of the Hashtable.</p>
2450
2451
2452 <h3><a name="MS_OOI_PKGPROTECT">MS: Field should be moved out of an interface and made package protected (MS_OOI_PKGPROTECT)</a></h3>
2453
2454
2455 <p>
2456  A final static field that is
2457 defined in an interface references a mutable
2458    object such as an array or hashtable.
2459    This mutable object could
2460    be changed by malicious code or
2461         by accident from another package.
2462    To solve this, the field needs to be moved to a class
2463    and made package protected
2464    to avoid
2465         this vulnerability.</p>
2466
2467
2468 <h3><a name="MS_PKGPROTECT">MS: Field should be package protected (MS_PKGPROTECT)</a></h3>
2469
2470
2471   <p> A mutable static field could be changed by malicious code or
2472    by accident.
2473    The field could be made package protected to avoid
2474    this vulnerability.</p>
2475
2476
2477 <h3><a name="MS_SHOULD_BE_FINAL">MS: Field isn't final but should be (MS_SHOULD_BE_FINAL)</a></h3>
2478
2479
2480    <p>
2481  A mutable static field could be changed by malicious code or
2482         by accident from another package.
2483         The field could be made final to avoid
2484         this vulnerability.</p>
2485
2486
2487 <h3><a name="DC_DOUBLECHECK">DC: Possible double check of field (DC_DOUBLECHECK)</a></h3>
2488
2489
2490   <p> This method may contain an instance of double-checked locking.&nbsp;
2491   This idiom is not correct according to the semantics of the Java memory
2492   model.&nbsp; For more information, see the web page
2493   <a href="http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html"
2494   >http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html</a>.</p>
2495
2496
2497 <h3><a name="DL_SYNCHRONIZATION_ON_SHARED_CONSTANT">DL: Synchronization on shared constant could lead to deadlock (DL_SYNCHRONIZATION_ON_SHARED_CONSTANT)</a></h3>
2498
2499
2500   <p> The code synchronizes on a shared primative constant, such as an interned String.
2501 <pre>
2502 private static String LOCK = "LOCK";
2503 ...
2504   synchronized(LOCK) { ...}
2505 ...
2506 </pre>
2507 </p>
2508 <p>Such constants an interned and shared across all other classes loaded by the JVM. Thus, this could
2509 is locking on something that other code might also be locking. This could result in very strange and hard to diagnose
2510 blocking and deadlock behavior. See <a href="http://www.javalobby.org/java/forums/t96352.html">http://www.javalobby.org/java/forums/t96352.html</a> and <a href="http://jira.codehaus.org/browse/JETTY-352">http://jira.codehaus.org/browse/JETTY-352</a>.
2511 </p>
2512
2513
2514 <h3><a name="DM_MONITOR_WAIT_ON_CONDITION">Dm: Monitor wait() called on Condition (DM_MONITOR_WAIT_ON_CONDITION)</a></h3>
2515
2516
2517       <p>
2518       This method calls <code>wait()</code> on a
2519       <code>java.util.concurrent.locks.Condition</code> object.&nbsp;
2520       Waiting for a <code>Condition</code> should be done using one of the <code>await()</code>
2521       methods defined by the <code>Condition</code> interface.
2522       </p>
2523
2524
2525 <h3><a name="DM_USELESS_THREAD">Dm: A thread was created using the default empty run method (DM_USELESS_THREAD)</a></h3>
2526
2527
2528   <p>This method creates a thread without specifying a run method either by deriving from the Thread class, or
2529   by passing a Runnable object. This thread, then, does nothing but waste time.
2530 </p>
2531
2532
2533 <h3><a name="ESync_EMPTY_SYNC">ESync: Empty synchronized block (ESync_EMPTY_SYNC)</a></h3>
2534
2535
2536   <p> The code contains an empty synchronized block:</p>
2537 <pre>
2538 synchronized() {}
2539 </pre>
2540 <p>Empty synchronized blocks are far more subtle and hard to use correctly
2541 than most people recognize, and empty synchronized blocks
2542 are almost never a better solution
2543 than less contrived solutions.
2544 </p>
2545
2546
2547 <h3><a name="IS2_INCONSISTENT_SYNC">IS: Inconsistent synchronization (IS2_INCONSISTENT_SYNC)</a></h3>
2548
2549
2550   <p> The fields of this class appear to be accessed inconsistently with respect
2551   to synchronization.&nbsp; This bug report indicates that the bug pattern detector
2552   judged that
2553   </p>
2554   <ol>
2555   <li> The class contains a mix of locked and unlocked accesses,</li>
2556   <li> At least one locked access was performed by one of the class's own methods, and</li>
2557   <li> The number of unsynchronized field accesses (reads and writes) was no more than
2558        one third of all accesses, with writes being weighed twice as high as reads</li>
2559   </ol>
2560
2561   <p> A typical bug matching this bug pattern is forgetting to synchronize
2562   one of the methods in a class that is intended to be thread-safe.</p>
2563
2564   <p> You can select the nodes labeled "Unsynchronized access" to show the
2565   code locations where the detector believed that a field was accessed
2566   without synchronization.</p>
2567
2568   <p> Note that there are various sources of inaccuracy in this detector;
2569   for example, the detector cannot statically detect all situations in which
2570   a lock is held.&nbsp; Also, even when the detector is accurate in
2571   distinguishing locked vs. unlocked accesses, the code in question may still
2572   be correct.</p>
2573
2574   <p> This description refers to the "IS2" version of the pattern detector,
2575   which has more accurate ways of detecting locked vs. unlocked accesses
2576   than the older "IS" detector.</p>
2577
2578
2579 <h3><a name="IS_FIELD_NOT_GUARDED">IS: Field not guarded against concurrent access (IS_FIELD_NOT_GUARDED)</a></h3>
2580
2581
2582   <p> This field is annotated with net.jcip.annotations.GuardedBy,
2583 but can be accessed in a way that seems to violate the annotation.</p>
2584
2585
2586 <h3><a name="JLM_JSR166_LOCK_MONITORENTER">JLM: Synchronization performed on java.util.concurrent Lock (JLM_JSR166_LOCK_MONITORENTER)</a></h3>
2587
2588
2589 <p> This method performs synchronization on an implementation of
2590 <code>java.util.concurrent.locks.Lock</code>.  You should use
2591 the <code>lock()</code> and <code>unlock()</code> methods instead.
2592 </p>
2593
2594
2595 <h3><a name="LI_LAZY_INIT_STATIC">LI: Incorrect lazy initialization of static field (LI_LAZY_INIT_STATIC)</a></h3>
2596
2597
2598 <p> This method contains an unsynchronized lazy initialization of a non-volatile static field.
2599 Because the compiler or processor may reorder instructions,
2600 threads are not guaranteed to see a completely initialized object,
2601 <em>if the method can be called by multiple threads</em>.
2602 You can make the field volatile to correct the problem.
2603 For more information, see the
2604 <a href="http://www.cs.umd.edu/~pugh/java/memoryModel/">Java Memory Model web site</a>.
2605 </p>
2606
2607
2608 <h3><a name="LI_LAZY_INIT_UPDATE_STATIC">LI: Incorrect lazy initialization and update of static field (LI_LAZY_INIT_UPDATE_STATIC)</a></h3>
2609
2610
2611 <p> This method contains an unsynchronized lazy initialization of a static field.
2612 After the field is set, the object stored into that location is further accessed.
2613 The setting of the field is visible to other threads as soon as it is set. If the
2614 futher accesses in the method that set the field serve to initialize the object, then
2615 you have a <em>very serious</em> multithreading bug, unless something else prevents
2616 any other thread from accessing the stored object until it is fully initialized.
2617 </p>
2618
2619
2620 <h3><a name="ML_SYNC_ON_UPDATED_FIELD">ML: Method synchronizes on an updated field (ML_SYNC_ON_UPDATED_FIELD)</a></h3>
2621
2622
2623   <p> This method synchronizes on an object
2624    references from a mutable field.
2625    This is unlikely to have useful semantics, since different
2626 threads may be synchronizing on different objects.</p>
2627
2628
2629 <h3><a name="MWN_MISMATCHED_NOTIFY">MWN: Mismatched notify() (MWN_MISMATCHED_NOTIFY)</a></h3>
2630
2631
2632 <p> This method calls Object.notify() or Object.notifyAll() without obviously holding a lock
2633 on the object.&nbsp;  Calling notify() or notifyAll() without a lock held will result in
2634 an <code>IllegalMonitorStateException</code> being thrown.</p>
2635
2636
2637 <h3><a name="MWN_MISMATCHED_WAIT">MWN: Mismatched wait() (MWN_MISMATCHED_WAIT)</a></h3>
2638
2639
2640 <p> This method calls Object.wait() without obviously holding a lock
2641 on the object.&nbsp;  Calling wait() without a lock held will result in
2642 an <code>IllegalMonitorStateException</code> being thrown.</p>
2643
2644
2645 <h3><a name="NN_NAKED_NOTIFY">NN: Naked notify (NN_NAKED_NOTIFY)</a></h3>
2646
2647
2648   <p> A call to <code>notify()</code> or <code>notifyAll()</code>
2649   was made without any (apparent) accompanying
2650   modification to mutable object state.&nbsp; In general, calling a notify
2651   method on a monitor is done because some condition another thread is
2652   waiting for has become true.&nbsp; However, for the condition to be meaningful,
2653   it must involve a heap object that is visible to both threads.</p>
2654
2655   <p> This bug does not necessarily indicate an error, since the change to
2656   mutable object state may have taken place in a method which then called
2657   the method containing the notification.</p>
2658
2659
2660 <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>
2661
2662
2663 <p>Since field is synchronized on, it seems not likely to be null.
2664 If it is null and then synchronized on a NullPointerException will be
2665 thrown and the check would be pointless. Better to synchronize on
2666 another field.</p>
2667
2668
2669
2670 <h3><a name="NO_NOTIFY_NOT_NOTIFYALL">No: Using notify() rather than notifyAll() (NO_NOTIFY_NOT_NOTIFYALL)</a></h3>
2671
2672
2673   <p> This method calls <code>notify()</code> rather than <code>notifyAll()</code>.&nbsp;
2674   Java monitors are often used for multiple conditions.&nbsp; Calling <code>notify()</code>
2675   only wakes up one thread, meaning that the thread woken up might not be the
2676   one waiting for the condition that the caller just satisfied.</p>
2677
2678
2679 <h3><a name="RS_READOBJECT_SYNC">RS: Class's readObject() method is synchronized (RS_READOBJECT_SYNC)</a></h3>
2680
2681
2682   <p> This serializable class defines a <code>readObject()</code> which is
2683   synchronized.&nbsp; By definition, an object created by deserialization
2684   is only reachable by one thread, and thus there is no need for
2685   <code>readObject()</code> to be synchronized.&nbsp; If the <code>readObject()</code>
2686   method itself is causing the object to become visible to another thread,
2687   that is an example of very dubious coding style.</p>
2688
2689
2690 <h3><a name="RU_INVOKE_RUN">Ru: Invokes run on a thread (did you mean to start it instead?) (RU_INVOKE_RUN)</a></h3>
2691
2692
2693   <p> This method explicitly invokes <code>run()</code> on an object.&nbsp;
2694   In general, classes implement the <code>Runnable</code> interface because
2695   they are going to have their <code>run()</code> method invoked in a new thread,
2696   in which case <code>Thread.start()</code> is the right method to call.</p>
2697
2698
2699 <h3><a name="SC_START_IN_CTOR">SC: Constructor invokes Thread.start() (SC_START_IN_CTOR)</a></h3>
2700
2701
2702   <p> The constructor starts a thread. This is likely to be wrong if
2703    the class is ever extended/subclassed, since the thread will be started
2704    before the subclass constructor is started.</p>
2705
2706
2707 <h3><a name="SP_SPIN_ON_FIELD">SP: Method spins on field (SP_SPIN_ON_FIELD)</a></h3>
2708
2709
2710   <p> This method spins in a loop which reads a field.&nbsp; The compiler
2711   may legally hoist the read out of the loop, turning the code into an
2712   infinite loop.&nbsp; The class should be changed so it uses proper
2713   synchronization (including wait and notify calls).</p>
2714
2715
2716 <h3><a name="STCAL_INVOKE_ON_STATIC_CALENDAR_INSTANCE">STCAL: Call to static Calendar (STCAL_INVOKE_ON_STATIC_CALENDAR_INSTANCE)</a></h3>
2717
2718
2719 <p>Even though the JavaDoc does not contain a hint about it, Calendars are inherently unsafe for multihtreaded use.
2720 The detector has found a call to an instance of Calendar that has been obtained via a static
2721 field. This looks suspicous.</p>
2722 <p>For more information on this see <a href="http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6231579">Sun Bug #6231579</a>
2723 and <a href="http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6178997">Sun Bug #6178997</a>.</p>
2724
2725
2726 <h3><a name="STCAL_INVOKE_ON_STATIC_DATE_FORMAT_INSTANCE">STCAL: Call to static DateFormat (STCAL_INVOKE_ON_STATIC_DATE_FORMAT_INSTANCE)</a></h3>
2727
2728
2729 <p>As the JavaDoc states, DateFormats are inherently unsafe for multithreaded use.
2730 The detector has found a call to an instance of DateFormat that has been obtained via a static
2731 field. This looks suspicous.</p>
2732 <p>For more information on this see <a href="http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6231579">Sun Bug #6231579</a>
2733 and <a href="http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6178997">Sun Bug #6178997</a>.</p>
2734
2735
2736 <h3><a name="STCAL_STATIC_CALENDAR_INSTANCE">STCAL: Static Calendar (STCAL_STATIC_CALENDAR_INSTANCE)</a></h3>
2737
2738
2739 <p>Even though the JavaDoc does not contain a hint about it, Calendars are inherently unsafe for multihtreaded use.
2740 Sharing a single instance across thread boundaries without proper synchronization will result in erratic behavior of the
2741 application. Under 1.4 problems seem to surface less often than under Java 5 where you will probably see
2742 random ArrayIndexOutOfBoundsExceptions or IndexOutOfBoundsExceptions in sun.util.calendar.BaseCalendar.getCalendarDateFromFixedDate().</p>
2743 <p>You may also experience serialization problems.</p>
2744 <p>Using an instance field is recommended.</p>
2745 <p>For more information on this see <a href="http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6231579">Sun Bug #6231579</a>
2746 and <a href="http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6178997">Sun Bug #6178997</a>.</p>
2747
2748
2749 <h3><a name="STCAL_STATIC_SIMPLE_DATE_FORMAT_INSTANCE">STCAL: Static DateFormat (STCAL_STATIC_SIMPLE_DATE_FORMAT_INSTANCE)</a></h3>
2750
2751
2752 <p>As the JavaDoc states, DateFormats are inherently unsafe for multithreaded use.
2753 Sharing a single instance across thread boundaries without proper synchronization will result in erratic behavior of the
2754 application.</p>
2755 <p>You may also experience serialization problems.</p>
2756 <p>Using an instance field is recommended.</p>
2757 <p>For more information on this see <a href="http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6231579">Sun Bug #6231579</a>
2758 and <a href="http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6178997">Sun Bug #6178997</a>.</p>
2759
2760
2761 <h3><a name="SWL_SLEEP_WITH_LOCK_HELD">SWL: Method calls Thread.sleep() with a lock held (SWL_SLEEP_WITH_LOCK_HELD)</a></h3>
2762
2763
2764       <p>
2765       This method calls Thread.sleep() with a lock held.  This may result
2766       in very poor performance and scalability, or a deadlock, since other threads may
2767       be waiting to acquire the lock.  It is a much better idea to call
2768       wait() on the lock, which releases the lock and allows other threads
2769       to run.
2770       </p>
2771
2772
2773 <h3><a name="TLW_TWO_LOCK_WAIT">TLW: Wait with two locks held (TLW_TWO_LOCK_WAIT)</a></h3>
2774
2775
2776   <p> Waiting on a monitor while two locks are held may cause
2777   deadlock.
2778    &nbsp;
2779    Performing a wait only releases the lock on the object
2780    being waited on, not any other locks.
2781    &nbsp;
2782 This not necessarily a bug, but is worth examining
2783   closely.</p>
2784
2785
2786 <h3><a name="UG_SYNC_SET_UNSYNC_GET">UG: Unsynchronized get method, synchronized set method (UG_SYNC_SET_UNSYNC_GET)</a></h3>
2787
2788
2789   <p> This class contains similarly-named get and set
2790   methods where the set method is synchronized and the get method is not.&nbsp;
2791   This may result in incorrect behavior at runtime, as callers of the get
2792   method will not necessarily see a consistent state for the object.&nbsp;
2793   The get method should be made synchronized.</p>
2794
2795
2796 <h3><a name="UL_UNRELEASED_LOCK">UL: Method does not release lock on all paths (UL_UNRELEASED_LOCK)</a></h3>
2797
2798
2799 <p> This method acquires a JSR-166 (<code>java.util.concurrent</code>) lock,
2800 but does not release it on all paths out of the method.  In general, the correct idiom
2801 for using a JSR-166 lock is:
2802 </p>
2803 <pre>
2804     Lock l = ...;
2805     l.lock();
2806     try {
2807         // do something
2808     } finally {
2809         l.unlock();
2810     }
2811 </pre>
2812
2813
2814 <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>
2815
2816
2817 <p> This method acquires a JSR-166 (<code>java.util.concurrent</code>) lock,
2818 but does not release it on all exception paths out of the method.  In general, the correct idiom
2819 for using a JSR-166 lock is:
2820 </p>
2821 <pre>
2822     Lock l = ...;
2823     l.lock();
2824     try {
2825         // do something
2826     } finally {
2827         l.unlock();
2828     }
2829 </pre>
2830
2831
2832 <h3><a name="UW_UNCOND_WAIT">UW: Unconditional wait (UW_UNCOND_WAIT)</a></h3>
2833
2834
2835   <p> This method contains a call to <code>java.lang.Object.wait()</code> which
2836   is not guarded by conditional control flow.&nbsp; The code should
2837         verify that condition it intends to wait for is not already satisfied
2838         before calling wait; any previous notifications will be ignored.
2839   </p>
2840
2841
2842 <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>
2843
2844
2845 <p>This declares a volatile reference to an array, which might not be what
2846 you want. With a volatile reference to an array, reads and writes of
2847 the reference to the array are treated as volatile, but the array elements
2848 are non-volatile. To get volatile array elements, you will need to use
2849 one of the atomic array classes in java.util.concurrent (provided
2850 in Java 5.0).</p>
2851
2852
2853 <h3><a name="WS_WRITEOBJECT_SYNC">WS: Class's writeObject() method is synchronized but nothing else is (WS_WRITEOBJECT_SYNC)</a></h3>
2854
2855
2856   <p> This class has a <code>writeObject()</code> method which is synchronized;
2857   however, no other method of the class is synchronized.</p>
2858
2859
2860 <h3><a name="WA_AWAIT_NOT_IN_LOOP">Wa: Condition.await() not in loop  (WA_AWAIT_NOT_IN_LOOP)</a></h3>
2861
2862
2863   <p> This method contains a call to <code>java.util.concurrent.await()</code>
2864    (or variants)
2865   which is not in a loop.&nbsp; If the object is used for multiple conditions,
2866   the condition the caller intended to wait for might not be the one
2867   that actually occurred.</p>
2868
2869
2870 <h3><a name="WA_NOT_IN_LOOP">Wa: Wait not in loop  (WA_NOT_IN_LOOP)</a></h3>
2871
2872
2873   <p> This method contains a call to <code>java.lang.Object.wait()</code>
2874   which is not in a loop.&nbsp; If the monitor is used for multiple conditions,
2875   the condition the caller intended to wait for might not be the one
2876   that actually occurred.</p>
2877
2878
2879 <h3><a name="BX_BOXING_IMMEDIATELY_UNBOXED">Bx: Primitive value is boxed and then immediately unboxed (BX_BOXING_IMMEDIATELY_UNBOXED)</a></h3>
2880
2881
2882   <p>A primitive is boxed, and then immediately unboxed. This probably is due to a manual
2883         boxing in a place where  an unboxed value is required, thus forcing the compiler
2884 to immediately undue the work of the boxing.
2885 </p>
2886
2887
2888 <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>
2889
2890
2891   <p>A primitive boxed value constructed and  then immediately converted into a different primitive type
2892 (e.g., <code>new Double(d).intValue()</code>). Just perform direct primitive coercion (e.g., <code>(int) d</code>).</p>
2893
2894
2895 <h3><a name="DM_BOXED_PRIMITIVE_TOSTRING">Bx: Method allocates a boxed primitive just to call toString (DM_BOXED_PRIMITIVE_TOSTRING)</a></h3>
2896
2897
2898   <p>A boxed primitive is allocated just to call toString(). It is more effective to just use the static
2899   form of toString which takes the primitive value. So,</p>
2900   <table>
2901      <tr><th>Replace...</th><th>With this...</th></tr>
2902      <tr><td>new Integer(1).toString()</td><td>Integer.toString(1)</td></tr>
2903      <tr><td>new Long(1).toString()</td><td>Long.toString(1)</td></tr>
2904      <tr><td>new Float(1.0).toString()</td><td>Float.toString(1.0)</td></tr>
2905      <tr><td>new Double(1.0).toString()</td><td>Double.toString(1.0)</td></tr>
2906      <tr><td>new Byte(1).toString()</td><td>Byte.toString(1)</td></tr>
2907      <tr><td>new Short(1).toString()</td><td>Short.toString(1)</td></tr>
2908      <tr><td>new Boolean(true).toString()</td><td>Boolean.toString(true)</td></tr>
2909   </table>
2910
2911
2912 <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>
2913
2914
2915       <p>
2916       Using <code>new Double(double)</code> is guaranteed to always result in a new object whereas
2917       <code>Double.valueOf(double)</code> allows caching of values to be done by the compiler, class library, or JVM.
2918       Using of cached values avoids object allocation and the code will be faster.
2919       </p>
2920       <p>
2921       Unless the class must be compatible with JVMs predating Java 1.5,
2922       use either autoboxing or the <code>valueOf()</code> method when creating instances of <code>Double</code> and <code>Float</code>.
2923       </p>
2924
2925
2926 <h3><a name="DM_NUMBER_CTOR">Bx: Method invokes inefficient Number constructor; use static valueOf instead (DM_NUMBER_CTOR)</a></h3>
2927
2928
2929       <p>
2930       Using <code>new Integer(int)</code> is guaranteed to always result in a new object whereas
2931       <code>Integer.valueOf(int)</code> allows caching of values to be done by the compiler, class library, or JVM.
2932       Using of cached values avoids object allocation and the code will be faster.
2933       </p>
2934       <p>
2935       Values between -128 and 127 are guaranteed to have corresponding cached instances
2936       and using <code>valueOf</code> is approximately 3.5 times faster than using constructor.
2937       For values outside the constant range the performance of both styles is the same.
2938       </p>
2939       <p>
2940       Unless the class must be compatible with JVMs predating Java 1.5,
2941       use either autoboxing or the <code>valueOf()</code> method when creating instances of
2942       <code>Long</code>, <code>Integer</code>, <code>Short</code>, <code>Character</code>, and <code>Byte</code>.
2943       </p>
2944
2945
2946 <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>
2947
2948
2949   <p> The equals and hashCode
2950 method of URL perform domain name resolution, this can result in a big performance hit.
2951 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.
2952 Consider using <code>java.net.URI</code> instead.
2953    </p>
2954
2955
2956 <h3><a name="DMI_COLLECTION_OF_URLS">Dm: Maps and sets of URLs can be performance hogs (DMI_COLLECTION_OF_URLS)</a></h3>
2957
2958
2959   <p> This method or field is or uses a Map or Set of URLs. Since both the equals and hashCode
2960 method of URL perform domain name resolution, this can result in a big performance hit.
2961 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.
2962 Consider using <code>java.net.URI</code> instead.
2963    </p>
2964
2965
2966 <h3><a name="DM_BOOLEAN_CTOR">Dm: Method invokes inefficient Boolean constructor; use Boolean.valueOf(...) instead (DM_BOOLEAN_CTOR)</a></h3>
2967
2968
2969   <p> Creating new instances of <code>java.lang.Boolean</code> wastes
2970   memory, since <code>Boolean</code> objects are immutable and there are
2971   only two useful values of this type.&nbsp; Use the <code>Boolean.valueOf()</code>
2972   method (or Java 1.5 autoboxing) to create <code>Boolean</code> objects instead.</p>
2973
2974
2975 <h3><a name="DM_GC">Dm: Explicit garbage collection; extremely dubious except in benchmarking code (DM_GC)</a></h3>
2976
2977
2978   <p> Code explicitly invokes garbage collection.
2979   Except for specific use in benchmarking, this is very dubious.</p>
2980   <p>In the past, situations where people have explicitly invoked
2981   the garbage collector in routines such as close or finalize methods
2982   has led to huge performance black holes. Garbage collection
2983    can be expensive. Any situation that forces hundreds or thousands
2984    of garbage collections will bring the machine to a crawl.</p>
2985
2986
2987 <h3><a name="DM_NEW_FOR_GETCLASS">Dm: Method allocates an object, only to get the class object (DM_NEW_FOR_GETCLASS)</a></h3>
2988
2989
2990   <p>This method allocates an object just to call getClass() on it, in order to
2991   retrieve the Class object for it. It is simpler to just access the .class property of the class.</p>
2992
2993
2994 <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>
2995
2996
2997   <p>If r is a java.util.Random, you can generate a random number from 0 to n-1
2998 using r.nextInt(n) Rather than using (int)(r.nextDouble() * n).
2999 </p>
3000
3001
3002 <h3><a name="DM_STRING_CTOR">Dm: Method invokes inefficient new String(String) constructor (DM_STRING_CTOR)</a></h3>
3003
3004
3005   <p> Using the <code>java.lang.String(String)</code> constructor wastes memory
3006   because the object so constructed will be functionally indistinguishable
3007   from the <code>String</code> passed as a parameter.&nbsp; Just use the
3008   argument <code>String</code> directly.</p>
3009
3010
3011 <h3><a name="DM_STRING_EMPTY_EQUALS">Dm: Method invokes inefficient String.equals(""); use String.length() == 0 instead (DM_STRING_EMPTY_EQUALS)</a></h3>
3012
3013
3014   <p> An object is compared to the empty String object using the equals() method here.
3015       Checking that the String object's length is zero may be faster, and removes String constants from the class file.</p>
3016
3017
3018 <h3><a name="DM_STRING_TOSTRING">Dm: Method invokes toString() method on a String (DM_STRING_TOSTRING)</a></h3>
3019
3020
3021   <p> Calling <code>String.toString()</code> is just a redundant operation.
3022   Just use the String.</p>
3023
3024
3025 <h3><a name="DM_STRING_VOID_CTOR">Dm: Method invokes inefficient new String() constructor (DM_STRING_VOID_CTOR)</a></h3>
3026
3027
3028   <p> Creating a new <code>java.lang.String</code> object using the
3029   no-argument constructor wastes memory because the object so created will
3030   be functionally indistinguishable from the empty string constant
3031   <code>""</code>.&nbsp; Java guarantees that identical string constants
3032   will be represented by the same <code>String</code> object.&nbsp; Therefore,
3033   you should just use the empty string constant directly.</p>
3034
3035
3036 <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>
3037
3038
3039       <p>
3040         A large String constant is duplicated across multiple class files.
3041         This is likely because a final field is initialized to a String constant, and the Java language
3042         mandates that all references to a final field from other classes be inlined into
3043 that classfile. See <a href="http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6447475">JDK bug 6447475</a>
3044         for a description of an occurrence of this bug in the JDK and how resolving it reduced
3045         the size of the JDK by 1 megabyte.
3046 </p>
3047
3048
3049 <h3><a name="ITA_INEFFICIENT_TO_ARRAY">ITA: Method uses toArray() with zero-length array argument (ITA_INEFFICIENT_TO_ARRAY)</a></h3>
3050
3051
3052 <p> This method uses the toArray() method of a collection derived class, and passes
3053 in a zero-length prototype array argument.  It is more efficient to use
3054 <code>myCollection.toArray(new Foo[myCollection.size()])</code>
3055 If the array passed in is big enough to store all of the
3056 elements of the collection, then it is populated and returned
3057 directly. This avoids the need to create a second array
3058 (by reflection) to return as the result.</p>
3059
3060
3061 <h3><a name="SBSC_USE_STRINGBUFFER_CONCATENATION">SBSC: Method concatenates strings using + in a loop (SBSC_USE_STRINGBUFFER_CONCATENATION)</a></h3>
3062
3063
3064 <p> The method seems to be building a String using concatenation in a loop.
3065 In each iteration, the String is converted to a StringBuffer/StringBuilder,
3066    appended to, and converted back to a String.
3067    This can lead to a cost quadratic in the number of iterations,
3068    as the growing string is recopied in each iteration. </p>
3069
3070 <p>Better performance can be obtained by using
3071 a StringBuffer (or StringBuilder in Java 1.5) explicitly.</p>
3072
3073 <p> For example:</p>
3074 <pre>
3075   // This is bad
3076   String s = "";
3077   for (int i = 0; i &lt; field.length; ++i) {
3078     s = s + field[i];
3079   }
3080
3081   // This is better
3082   StringBuffer buf = new StringBuffer();
3083   for (int i = 0; i &lt; field.length; ++i) {
3084     buf.append(field[i]);
3085   }
3086   String s = buf.toString();
3087 </pre>
3088
3089
3090 <h3><a name="SIC_INNER_SHOULD_BE_STATIC">SIC: Should be a static inner class (SIC_INNER_SHOULD_BE_STATIC)</a></h3>
3091
3092
3093   <p> This class is an inner class, but does not use its embedded reference
3094   to the object which created it.&nbsp; This reference makes the instances
3095   of the class larger, and may keep the reference to the creator object
3096   alive longer than necessary.&nbsp; If possible, the class should be
3097    made static.
3098 </p>
3099
3100
3101 <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>
3102
3103
3104   <p> This class is an inner class, but does not use its embedded reference
3105   to the object which created it.&nbsp; This reference makes the instances
3106   of the class larger, and may keep the reference to the creator object
3107   alive longer than necessary.&nbsp; If possible, the class should be
3108   made into a <em>static</em> inner class. Since anonymous inner
3109 classes cannot be marked as static, doing this will requiring refactoring
3110 the inner class so that it is a named inner class.</p>
3111
3112
3113 <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>
3114
3115
3116   <p> This class is an inner class, but does not use its embedded reference
3117   to the object which created it except during construction of the
3118 inner object.&nbsp; This reference makes the instances
3119   of the class larger, and may keep the reference to the creator object
3120   alive longer than necessary.&nbsp; If possible, the class should be
3121   made into a <em>static</em> inner class. Since the reference to the
3122    outer object is required during construction of the inner instance,
3123    the inner class will need to be refactored so as to
3124    pass  a reference to the outer instance to the constructor
3125    for the inner class.</p>
3126
3127
3128 <h3><a name="SS_SHOULD_BE_STATIC">SS: Unread field: should this field be static? (SS_SHOULD_BE_STATIC)</a></h3>
3129
3130
3131   <p> This class contains an instance final field that
3132    is initialized to a compile-time static value.
3133    Consider making the field static.</p>
3134
3135
3136 <h3><a name="UM_UNNECESSARY_MATH">UM: Method calls static Math class method on a constant value (UM_UNNECESSARY_MATH)</a></h3>
3137
3138
3139 <p> This method uses a static method from java.lang.Math on a constant value. This method's
3140 result in this case, can be determined statically, and is faster and sometimes more accurate to
3141 just use the constant. Methods detected are:
3142 </p>
3143 <table>
3144 <tr>
3145    <th>Method</th> <th>Parameter</th>
3146 </tr>
3147 <tr>
3148    <td>abs</td> <td>-any-</td>
3149 </tr>
3150 <tr>
3151    <td>acos</td> <td>0.0 or 1.0</td>
3152 </tr>
3153 <tr>
3154    <td>asin</td> <td>0.0 or 1.0</td>
3155 </tr>
3156 <tr>
3157    <td>atan</td> <td>0.0 or 1.0</td>
3158 </tr>
3159 <tr>
3160    <td>atan2</td> <td>0.0</td>
3161 </tr>
3162 <tr>
3163    <td>cbrt</td> <td>0.0 or 1.0</td>
3164 </tr>
3165 <tr>
3166    <td>ceil</td> <td>-any-</td>
3167 </tr>
3168 <tr>
3169    <td>cos</td> <td>0.0</td>
3170 </tr>
3171 <tr>
3172    <td>cosh</td> <td>0.0</td>
3173 </tr>
3174 <tr>
3175    <td>exp</td> <td>0.0 or 1.0</td>
3176 </tr>
3177 <tr>
3178    <td>expm1</td> <td>0.0</td>
3179 </tr>
3180 <tr>
3181    <td>floor</td> <td>-any-</td>
3182 </tr>
3183 <tr>
3184    <td>log</td> <td>0.0 or 1.0</td>
3185 </tr>
3186 <tr>
3187    <td>log10</td> <td>0.0 or 1.0</td>
3188 </tr>
3189 <tr>
3190    <td>rint</td> <td>-any-</td>
3191 </tr>
3192 <tr>
3193    <td>round</td> <td>-any-</td>
3194 </tr>
3195 <tr>
3196    <td>sin</td> <td>0.0</td>
3197 </tr>
3198 <tr>
3199    <td>sinh</td> <td>0.0</td>
3200 </tr>
3201 <tr>
3202    <td>sqrt</td> <td>0.0 or 1.0</td>
3203 </tr>
3204 <tr>
3205    <td>tan</td> <td>0.0</td>
3206 </tr>
3207 <tr>
3208    <td>tanh</td> <td>0.0</td>
3209 </tr>
3210 <tr>
3211    <td>toDegrees</td> <td>0.0 or 1.0</td>
3212 </tr>
3213 <tr>
3214    <td>toRadians</td> <td>0.0</td>
3215 </tr>
3216 </table>
3217
3218
3219 <h3><a name="UPM_UNCALLED_PRIVATE_METHOD">UPM: Private method is never called (UPM_UNCALLED_PRIVATE_METHOD)</a></h3>
3220
3221
3222 <p> This private method is never called. Although it is
3223 possible that the method will be invoked through reflection,
3224 it is more likely that the method is never used, and should be
3225 removed.
3226 </p>
3227
3228
3229 <h3><a name="URF_UNREAD_FIELD">UrF: Unread field (URF_UNREAD_FIELD)</a></h3>
3230
3231
3232   <p> This field is never read.&nbsp; Consider removing it from the class.</p>
3233
3234
3235 <h3><a name="UUF_UNUSED_FIELD">UuF: Unused field (UUF_UNUSED_FIELD)</a></h3>
3236
3237
3238   <p> This field is never used.&nbsp; Consider removing it from the class.</p>
3239
3240
3241 <h3><a name="WMI_WRONG_MAP_ITERATOR">WMI: Inefficient use of keySet iterator instead of entrySet iterator (WMI_WRONG_MAP_ITERATOR)</a></h3>
3242
3243
3244 <p> This method accesses the value of a Map entry, using a key that was retrieved from
3245 a keySet iterator. It is more efficient to use an iterator on the entrySet of the map, to avoid the
3246 Map.get(key) lookup.</p>
3247
3248
3249 <h3><a name="BC_BAD_CAST_TO_ABSTRACT_COLLECTION">BC: Questionable cast to abstract collection  (BC_BAD_CAST_TO_ABSTRACT_COLLECTION)</a></h3>
3250
3251
3252 <p>
3253 This code casts a Collection to an abstract collection
3254 (such as <code>List</code>, <code>Set</code>, or <code>Map</code>).
3255 Ensure that you are guaranteed that the object is of the type
3256 you are casting to. If all you need is to be able
3257 to iterate through a collection, you don't need to cast it to a Set or List.
3258 </p>
3259
3260
3261 <h3><a name="BC_BAD_CAST_TO_CONCRETE_COLLECTION">BC: Questionable cast to concrete collection (BC_BAD_CAST_TO_CONCRETE_COLLECTION)</a></h3>
3262
3263
3264 <p>
3265 This code casts an abstract collection (such as a Collection, List, or Set)
3266 to a specific concrete implementation (such as an ArrayList or HashSet).
3267 This might not be correct, and it may make your code fragile, since
3268 it makes it harder to switch to other concrete implementations at a future
3269 point. Unless you have a particular reason to do so, just use the abstract
3270 collection class.
3271 </p>
3272
3273
3274 <h3><a name="BC_UNCONFIRMED_CAST">BC: Unchecked/unconfirmed cast (BC_UNCONFIRMED_CAST)</a></h3>
3275
3276
3277 <p>
3278 This cast is unchecked, and not all instances of the type casted from can be cast to
3279 the type it is being cast to. Ensure that your program logic ensures that this
3280 cast will not fail.
3281 </p>
3282
3283
3284 <h3><a name="BC_VACUOUS_INSTANCEOF">BC: instanceof will always return true (BC_VACUOUS_INSTANCEOF)</a></h3>
3285
3286
3287 <p>
3288 This instanceof test will always return true. Although this is safe, make sure it isn't
3289 an indication of some misunderstanding or some other logic error.
3290 </p>
3291
3292
3293 <h3><a name="CI_CONFUSED_INHERITANCE">CI: Class is final but declares protected field (CI_CONFUSED_INHERITANCE)</a></h3>
3294
3295
3296       <p>
3297       This class is declared to be final, but declares fields to be protected. Since the class
3298       is final, it can not be derived from, and the use of protected is confusing. The access
3299       modifier for the field should be changed to private or public to represent the true
3300       use for the field.
3301       </p>
3302
3303
3304 <h3><a name="DB_DUPLICATE_BRANCHES">DB: Method uses the same code for two branches (DB_DUPLICATE_BRANCHES)</a></h3>
3305
3306
3307       <p>
3308       This method uses the same code to implement two branches of a conditional branch.
3309         Check to ensure that this isn't a coding mistake.
3310       </p>
3311
3312
3313 <h3><a name="DB_DUPLICATE_SWITCH_CLAUSES">DB: Method uses the same code for two switch clauses (DB_DUPLICATE_SWITCH_CLAUSES)</a></h3>
3314
3315
3316       <p>
3317       This method uses the same code to implement two clauses of a switch statement.
3318         This could be a case of duplicate code, but it might also indicate
3319         a coding mistake.
3320       </p>
3321
3322
3323 <h3><a name="DLS_DEAD_LOCAL_STORE">DLS: Dead store to local variable (DLS_DEAD_LOCAL_STORE)</a></h3>
3324
3325
3326 <p>
3327 This instruction assigns a value to a local variable,
3328 but the value is not read by any subsequent instruction.
3329 Often, this indicates an error, because the value computed
3330 is never used.
3331 </p>
3332 <p>
3333 Note that Sun's javac compiler often generates dead stores for
3334 final local variables.  Because FindBugs is a bytecode-based tool,
3335 there is no easy way to eliminate these false positives.
3336 </p>
3337
3338
3339 <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>
3340
3341
3342 <p>The code stores null into a local variable, and stored value is not
3343 read. This store may have been introduced in assist the garbage collector, but
3344 as of Java SE 6.0, this is no longer needed or useful.
3345 </p>
3346
3347
3348 <h3><a name="DMI_HARDCODED_ABSOLUTE_FILENAME">DMI: Code contains a hard coded reference to an absolute pathname (DMI_HARDCODED_ABSOLUTE_FILENAME)</a></h3>
3349
3350
3351 <p>This code constructs a File object using a hard coded to an absolute pathname
3352 (e.g., <code>new File("/home/dannyc/workspace/j2ee/src/share/com/sun/enterprise/deployment");</code>
3353 </p>
3354
3355
3356 <h3><a name="DMI_NONSERIALIZABLE_OBJECT_WRITTEN">DMI: Non serializable object written to ObjectOutput (DMI_NONSERIALIZABLE_OBJECT_WRITTEN)</a></h3>
3357
3358
3359 <p>
3360 This code seems to be passing a non-serializable object to the ObjectOutput.writeObject method.
3361 If the object is, indeed, non-serializable, an error will result.
3362 </p>
3363
3364
3365 <h3><a name="DMI_USELESS_SUBSTRING">DMI: Invocation of substring(0), which returns the original value (DMI_USELESS_SUBSTRING)</a></h3>
3366
3367
3368 <p>
3369 This code invokes substring(0) on a String, which returns the original value.
3370 </p>
3371
3372
3373 <h3><a name="DMI_THREAD_PASSED_WHERE_RUNNABLE_EXPECTED">Dm: Thread passed where Runnable expected (DMI_THREAD_PASSED_WHERE_RUNNABLE_EXPECTED)</a></h3>
3374
3375
3376   <p> A Thread object is passed as a parameter to a method where
3377 a Runnable is expected. This is rather unusual, and may indicate a logic error
3378 or cause unexpected behavior.
3379    </p>
3380
3381
3382 <h3><a name="EQ_DOESNT_OVERRIDE_EQUALS">Eq: Class doesn't override equals in superclass (EQ_DOESNT_OVERRIDE_EQUALS)</a></h3>
3383
3384
3385   <p> This class extends a class that defines an equals method and adds fields, but doesn't
3386 define an equals method itself. Thus, equality on instances of this class will
3387 ignore the identity of the subclass and the added fields. Be sure this is what is intended,
3388 and that you don't need to override the equals method. Even if you don't need to override
3389 the equals method, consider overriding it anyone to document the fact
3390 that the equals method for the subclass just return the result of
3391 invoking super.equals(o).
3392
3393
3394 <h3><a name="FE_FLOATING_POINT_EQUALITY">FE: Test for floating point equality (FE_FLOATING_POINT_EQUALITY)</a></h3>
3395
3396
3397     <p>
3398     This operation compares two floating point values for equality.
3399     Because floating point calculations may involve rounding,
3400    calculated float and double values may not be accurate.
3401     For values that must be precise, such as monetary values,
3402    consider using a fixed-precision type such as BigDecimal.
3403     For values that need not be precise, consider comparing for equality
3404     within some range, for example:
3405     <code>if ( Math.abs(x - y) &lt; .0000001 )</code>.
3406    See the Java Language Specification, section 4.2.4.
3407     </p>
3408
3409
3410 <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>
3411
3412
3413   <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,
3414 it will be resolved to invoke the inherited method, but this may not be want
3415 you intend. If you really intend to invoke the inherited method,
3416 invoke it by invoking the method on super (e.g., invoke super.foo(17)), and
3417 thus it will be clear to other readers of your code and to FindBugs
3418 that you want to invoke the inherited method, not the method in the outer class.
3419 </p>
3420
3421
3422 <h3><a name="IC_INIT_CIRCULARITY">IC: Initialization circularity (IC_INIT_CIRCULARITY)</a></h3>
3423
3424
3425   <p> A circularity was detected in the static initializers of the two
3426   classes referenced by the bug instance.&nbsp; Many kinds of unexpected
3427   behavior may arise from such circularity.</p>
3428
3429
3430 <h3><a name="ICAST_IDIV_CAST_TO_DOUBLE">ICAST: int division result cast to double or float (ICAST_IDIV_CAST_TO_DOUBLE)</a></h3>
3431
3432
3433 <p>
3434 This code casts the result of an integer division operation to double or
3435 float.
3436 Doing division on integers truncates the result
3437 to the integer value closest to zero.  The fact that the result
3438 was cast to double suggests that this precision should have been retained.
3439 What was probably meant was to cast one or both of the operands to
3440 double <em>before</em> performing the division.  Here is an example:
3441 </p>
3442 <blockquote>
3443 <pre>
3444 int x = 2;
3445 int y = 5;
3446 // Wrong: yields result 0.0
3447 double value1 =  x / y;
3448
3449 // Right: yields result 0.4
3450 double value2 =  x / (double) y;
3451 </pre>
3452 </blockquote>
3453
3454
3455 <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>
3456
3457
3458 <p>
3459 This code performs integer multiply and then converts the result to a long,
3460 as in:
3461 <code>
3462 <pre>
3463         long convertDaysToMilliseconds(int days) { return 1000*3600*24*days; }
3464 </pre></code>
3465 If the multiplication is done using long arithmetic, you can avoid
3466 the possibility that the result will overflow. For example, you
3467 could fix the above code to:
3468 <code>
3469 <pre>
3470         long convertDaysToMilliseconds(int days) { return 1000L*3600*24*days; }
3471 </pre></code>
3472 or
3473 <code>
3474 <pre>
3475         static final long MILLISECONDS_PER_DAY = 24L*3600*1000;
3476         long convertDaysToMilliseconds(int days) { return days * MILLISECONDS_PER_DAY; }
3477 </pre></code>
3478 </p>
3479
3480
3481
3482 <h3><a name="ICAST_QUESTIONABLE_UNSIGNED_RIGHT_SHIFT">ICAST: Unsigned right shift cast to short/byte (ICAST_QUESTIONABLE_UNSIGNED_RIGHT_SHIFT)</a></h3>
3483
3484
3485 <p>
3486 The code performs an unsigned right shift, whose result is then
3487 cast to a short or byte, which discards the upper bits of the result.
3488 Since the upper bits are discarded, there may be no difference between
3489 a signed and unsigned right shift (depending upon the size of the shift).
3490 </p>
3491
3492
3493 <h3><a name="IM_AVERAGE_COMPUTATION_COULD_OVERFLOW">IM: Computation of average could overflow (IM_AVERAGE_COMPUTATION_COULD_OVERFLOW)</a></h3>
3494
3495
3496 <p>The code computes the average of two integers using either division or signed right shift,
3497 and then uses the result as the index of an array.
3498 If the values being averaged are very large, this can overflow (resulting in the computation
3499 of a negative average).  Assuming that the result is intended to be nonnegative, you
3500 can use an unsigned right shift instead. In other words, rather that using <code>(low+high)/2</code>,
3501 use <code>(low+high) &gt;&gt;&gt; 1</code>
3502 </p>
3503 <p>This bug exists in many earlier implementations of binary search and merge sort.
3504 Martin Buchholz <a href="http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6412541">found and fixed it</a>
3505 in the JDK libraries, and Joshua Bloch
3506 <a href="http://googleresearch.blogspot.com/2006/06/extra-extra-read-all-about-it-nearly.html">widely
3507 publicized the bug pattern</a>.
3508 </p>
3509
3510
3511 <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>
3512
3513
3514 <p>
3515 The code uses x % 2 == 1 to check to see if a value is odd, but this won't work
3516 for negative numbers (e.g., (-5) % 2 == -1). If this code is intending to check
3517 for oddness, consider using x & 1 == 1, or x % 2 != 0.
3518 </p>
3519
3520
3521 <h3><a name="INT_VACUOUS_COMPARISON">INT: Vacuous comparison of integer value (INT_VACUOUS_COMPARISON)</a></h3>
3522
3523
3524 <p> There is an integer comparison that always returns
3525 the same value (e.g., x <= Integer.MAX_VALUE).
3526 </p>
3527
3528
3529 <h3><a name="MTIA_SUSPECT_SERVLET_INSTANCE_FIELD">MTIA: Class extends Servlet class and uses instance variables (MTIA_SUSPECT_SERVLET_INSTANCE_FIELD)</a></h3>
3530
3531
3532     <p>
3533     This class extends from a Servlet class, and uses a instance member variable. Since only
3534     one instance of a Servlet class is created by the J2EE framework, and used in a
3535     multithreaded way, this paradigm is highly discouraged and most likely problematic. Consider
3536     only using method local variables.
3537     </p>
3538
3539
3540 <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>
3541
3542
3543     <p>
3544     This class extends from a Struts Action class, and uses a instance member variable. Since only
3545     one instance of a struts Action class is created by the Struts framework, and used in a
3546     multithreaded way, this paradigm is highly discouraged and most likely problematic. Consider
3547     only using method local variables.
3548     </p>
3549
3550
3551 <h3><a name="NP_IMMEDIATE_DEREFERENCE_OF_READLINE">NP: Immediate dereference of the result of readLine() (NP_IMMEDIATE_DEREFERENCE_OF_READLINE)</a></h3>
3552
3553
3554   <p> The result of invoking readLine() is immediately dereferenced. If there are no more lines of text
3555 to read, readLine() will return null and dereferencing that will generate a null pointer exception.
3556 </p>
3557
3558
3559 <h3><a name="NP_LOAD_OF_KNOWN_NULL_VALUE">NP: Load of known null value (NP_LOAD_OF_KNOWN_NULL_VALUE)</a></h3>
3560
3561
3562   <p> The variable referenced at this point is known to be null due to an earlier
3563    check against null. Although this is valid, it might be a mistake (perhaps you
3564 intended to refer to a different variable, or perhaps the earlier check to see if the
3565 variable is null should have been a check to see if it was nonnull.
3566 </p>
3567
3568
3569 <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>
3570
3571
3572 <p> A reference value which is null on some exception control path is
3573 dereferenced here.&nbsp; This may lead to a <code>NullPointerException</code>
3574 when the code is executed.&nbsp; The value may be null because it
3575 was return from a method which is known to return possibly-null values.</p>
3576
3577
3578 <h3><a name="NS_DANGEROUS_NON_SHORT_CIRCUIT">NS: Potentially dangerous use of non-short-circuit logic (NS_DANGEROUS_NON_SHORT_CIRCUIT)</a></h3>
3579
3580
3581   <p> This code seems to be using non-short-circuit logic (e.g., &amp;
3582 or |)
3583 rather than short-circuit logic (&amp;&amp; or ||). In addition,
3584 it seem possible that, depending on the value of the left hand side, you might not
3585 want to evaluate the right hand side (because it would have side effects, could cause an exception
3586 or could be expensive.</p>
3587 <p>
3588 Non-short-circuit logic causes both sides of the expression
3589 to be evaluated even when the result can be inferred from
3590 knowing the left-hand side. This can be less efficient and
3591 can result in errors if the left-hand side guards cases
3592 when evaluating the right-hand side can generate an error.
3593 </p>
3594
3595 <p>See <a href="http://java.sun.com/docs/books/jls/third_edition/html/expressions.html#15.22.2">the Java
3596 Language Specification</a> for details
3597
3598 </p>
3599
3600
3601 <h3><a name="NS_NON_SHORT_CIRCUIT">NS: Questionable use of non-short-circuit logic (NS_NON_SHORT_CIRCUIT)</a></h3>
3602
3603
3604   <p> This code seems to be using non-short-circuit logic (e.g., &amp;
3605 or |)
3606 rather than short-circuit logic (&amp;&amp; or ||).
3607 Non-short-circuit logic causes both sides of the expression
3608 to be evaluated even when the result can be inferred from
3609 knowing the left-hand side. This can be less efficient and
3610 can result in errors if the left-hand side guards cases
3611 when evaluating the right-hand side can generate an error.
3612
3613 <p>See <a href="http://java.sun.com/docs/books/jls/third_edition/html/expressions.html#15.22.2">the Java
3614 Language Specification</a> for details
3615
3616 </p>
3617
3618
3619 <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>
3620
3621
3622 <p> It is often a better design to
3623 return a length zero array rather than a null reference to indicate that there
3624 are no results (i.e., an empty list of results).
3625 This way, no explicit check for null is needed by clients of the method.</p>
3626
3627 <p>On the other hand, using null to indicate
3628 "there is no answer to this question", then it is probably appropriate.
3629 For example, <code>File.listFiles()</code> returns an empty list
3630 if given a directory containing no files, and returns null if the file
3631 is not a directory.</p>
3632
3633
3634 <h3><a name="QF_QUESTIONABLE_FOR_LOOP">QF: Complicated, subtle or wrong increment in for-loop  (QF_QUESTIONABLE_FOR_LOOP)</a></h3>
3635
3636
3637    <p>Are you sure this for loop is incrementing the correct variable?
3638    It appears that another variable is being initialized and checked
3639    by the for loop.
3640 </p>
3641
3642
3643 <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>
3644
3645
3646 <p> This method contains a reference known to be non-null with another reference
3647 known to be null.</p>
3648
3649
3650 <h3><a name="RCN_REDUNDANT_COMPARISON_TWO_NULL_VALUES">RCN: Redundant comparison of two null values (RCN_REDUNDANT_COMPARISON_TWO_NULL_VALUES)</a></h3>
3651
3652
3653 <p> This method contains a redundant comparison of two references known to
3654 both be definitely null.</p>
3655
3656
3657 <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>
3658
3659
3660 <p> This method contains a redundant check of a known non-null value against
3661 the constant null.</p>
3662
3663
3664 <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>
3665
3666
3667 <p> This method contains a redundant check of a known null value against
3668 the constant null.</p>
3669
3670
3671 <h3><a name="REC_CATCH_EXCEPTION">REC: Exception is caught when Exception is not thrown (REC_CATCH_EXCEPTION)</a></h3>
3672
3673
3674   <p>
3675   This method uses a try-catch block that catches Exception objects, but Exception is not
3676   thrown within the try block, and RuntimeException is not explicitly caught.  It is a common bug pattern to
3677   say try { ... } catch (Exception e) { something } as a shorthand for catching a number of types of exception
3678   each of whose catch blocks is identical, but this construct also accidentally catches RuntimeException as well,
3679   masking potential bugs.
3680   </p>
3681
3682
3683 <h3><a name="RI_REDUNDANT_INTERFACES">RI: Class implements same interface as superclass (RI_REDUNDANT_INTERFACES)</a></h3>
3684
3685
3686     <p>
3687     This class declares that it implements an interface that is also implemented by a superclass.
3688     This is redundant, once a superclass implements an interface, all subclasses by default also
3689     implement this interface. It may point out that the inheritance hierarchy has changed since
3690     this class was created, and consideration should be taken into account for the ownership of
3691     the interface's implementation.
3692     </p>
3693
3694
3695 <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>
3696
3697
3698    <p> The method invokes String.indexOf and checks to see if the result is positive or non-positive.
3699    It is much more typical to check to see if the result is negative or non-negative. It is
3700    positive only if the substring checked for occurs at some place other than at the beginning of
3701    the String.</p>
3702
3703
3704 <h3><a name="RV_REM_OF_HASHCODE">RV: Remainder of hashCode could be negative (RV_REM_OF_HASHCODE)</a></h3>
3705
3706
3707 <p> This code computes a hashCode, and then computes
3708 the remainder of that value modulo another value. Since the hashCode
3709 can be negative, the result of the remainder operation
3710 can also be negative. </p>
3711 <p> Assuming you want to ensure that the result of your computation is nonnegative,
3712 you may need to change your code.
3713 If you know the divisor is a power of 2,
3714 you can use a bitwise and operator instead (i.e., instead of
3715 using <code>x.hashCode()%n</code>, use <code>x.hashCode()&amp;(n-1)</code>.
3716 This is probably faster than computing the remainder as well.
3717 If you don't know that the divisor is a power of 2, take the absolute
3718 value of the result of the remainder operation (i.e., use
3719 <code>Math.abs(x.hashCode()%n)</code>
3720 </p>
3721
3722
3723 <h3><a name="RV_REM_OF_RANDOM_INT">RV: Remainder of 32-bit signed random integer (RV_REM_OF_RANDOM_INT)</a></h3>
3724
3725
3726 <p> This code generates a random signed integer and then computes
3727 the remainder of that value modulo another value. Since the random
3728 number can be negative, the result of the remainder operation
3729 can also be negative. Be sure this is intended, and strongly
3730 consider using the Random.nextInt(int) method instead.
3731 </p>
3732
3733
3734 <h3><a name="SA_LOCAL_SELF_ASSIGNMENT">SA: Self assignment of local variable (SA_LOCAL_SELF_ASSIGNMENT)</a></h3>
3735
3736
3737 <p> This method contains a self assignment of a local variable; e.g.</p>
3738 <pre>
3739   public void foo() {
3740     int x = 3;
3741     x = x;
3742   }
3743 </pre>
3744 <p>
3745 Such assignments are useless, and may indicate a logic error or typo.
3746 </p>
3747
3748
3749 <h3><a name="SF_SWITCH_FALLTHROUGH">SF: Switch statement found where one case falls through to the next case (SF_SWITCH_FALLTHROUGH)</a></h3>
3750
3751
3752   <p> This method contains a switch statement where one case branch will fall through to the next case.
3753   Usually you need to end this case with a break or return.</p>
3754
3755
3756 <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>
3757
3758
3759   <p> This instance method writes to a static field. This is tricky to get
3760 correct if multiple instances are being manipulated,
3761 and generally bad practice.
3762 </p>
3763
3764
3765 <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>
3766
3767
3768   <p> The field is marked as transient, but the class isn't Serializable, so marking it as transient
3769 has absolutely no effect.
3770 This may be leftover marking from a previous version of the code in which the class was transient, or
3771 it may indicate a misunderstanding of how serialization works.
3772 </p>
3773
3774
3775 <h3><a name="UCF_USELESS_CONTROL_FLOW">UCF: Useless control flow (UCF_USELESS_CONTROL_FLOW)</a></h3>
3776
3777
3778 <p> This method contains a useless control flow statement, where
3779 control flow continues onto the same place regardless of whether or not
3780 the branch is taken. For example,
3781 this is caused by having an empty statement
3782 block fot an <code>if</code> statement:</p>
3783 <pre>
3784     if (argv.length == 0) {
3785         // TODO: handle this case
3786         }
3787 </pre>
3788
3789
3790 <h3><a name="UWF_FIELD_NOT_INITIALIZED_IN_CONSTRUCTOR">UwF: Field not initialized in constructor (UWF_FIELD_NOT_INITIALIZED_IN_CONSTRUCTOR)</a></h3>
3791
3792
3793   <p> This field is never initialized within any constructor, and is therefore could be null after
3794 the object is constructed.
3795 This could be a either an error or a questionable design, since
3796 it means a null pointer exception will be generated if that field is dereferenced
3797 before being initialized.
3798 </p>
3799
3800
3801 <h3><a name="XFB_XML_FACTORY_BYPASS">XFB: Method directly allocates a specific implementation of xml interfaces (XFB_XML_FACTORY_BYPASS)</a></h3>
3802
3803
3804       <p>
3805       This method allocates a specific implementation of an xml interface. It is preferable to use
3806       the supplied factory classes to create these objects so that the implementation can be
3807       changed at runtime. See
3808       </p>
3809       <ul>
3810          <li>javax.xml.parsers.DocumentBuilderFactory</li>
3811          <li>javax.xml.parsers.SAXParserFactory</li>
3812          <li>javax.xml.transform.TransformerFactory</li>
3813          <li>org.w3c.dom.Document.create<i>XXXX</i></li>
3814       </ul>
3815       <p>for details.</p>
3816
3817
3818
3819
3820 <hr> <p>
3821 <script language="JavaScript" type="text/javascript">
3822 <!---//hide script from old browsers
3823 document.write( "Last updated "+ document.lastModified + "." );
3824 //end hiding contents --->
3825 </script>
3826 <p> Send comments to <a class="sidebar" href="mailto:findbugs@cs.umd.edu">findbugs@cs.umd.edu</a>
3827 <p>
3828 <A href="http://sourceforge.net"><IMG src="http://sourceforge.net/sflogo.php?group_id=96405&amp;type=5" width="210" height="62" border="0" alt="SourceForge.net Logo" /></A>
3829 </td></tr></table>
3830 </body></html>