1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> 2 <html><head><title>FindBugs Bug Descriptions</title> 3 <link rel="stylesheet" type="text/css" href="findbugs.css"/> 4 <link rel="shortcut icon" href="favicon.ico" type="image/x-icon"/> 5 </head><body> 6 7 <table width="100%"><tr> 8 9 <td bgcolor="#b9b9fe" valign="top" align="left" width="20%"> 10 <table width="100%" cellspacing="0" border="0"> 11 <tr><td><a class="sidebar" href="index.html"><img src="umdFindbugs.png" alt="FindBugs"></a></td></tr> 12 13 <tr><td> </td></tr> 14 15 <tr><td><b>Docs and Info</b></td></tr> 16 <tr><td><font size="-1"><a class="sidebar" href="findbugs2.html">FindBugs 2.0</a></font></td></tr> 17 <tr><td><font size="-1"><a class="sidebar" href="demo.html">Demo and data</a></font></td></tr> 18 <tr><td><font size="-1"><a class="sidebar" href="users.html">Users and supporters</a></font></td></tr> 19 <tr><td><font size="-1"><a class="sidebar" href="http://findbugs.blogspot.com/">FindBugs blog</a></font></td></tr> 20 <tr><td><font size="-1"><a class="sidebar" href="factSheet.html">Fact sheet</a></font></td></tr> 21 <tr><td><font size="-1"><a class="sidebar" href="manual/index.html">Manual</a></font></td></tr> 22 <tr><td><font size="-1"><a class="sidebar" href="ja/manual/index.html">Manual(ja/日本語)</a></font></td></tr> 23 <tr><td><font size="-1"><a class="sidebar" href="FAQ.html">FAQ</a></font></td></tr> 24 <tr><td><font size="-1"><a class="sidebar" href="bugDescriptions.html">Bug descriptions</a></font></td></tr> 25 <tr><td><font size="-1"><a class="sidebar" href="mailingLists.html">Mailing lists</a></font></td></tr> 26 <tr><td><font size="-1"><a class="sidebar" href="publications.html">Documents and Publications</a></font></td></tr> 27 <tr><td><font size="-1"><a class="sidebar" href="links.html">Links</a></font></td></tr> 28 29 <tr><td> </td></tr> 30 31 <tr><td><a class="sidebar" href="downloads.html"><b>Downloads</b></a></td></tr> 32 33 <tr><td> </td></tr> 34 35 <tr><td><a class="sidebar" href="http://www.cafeshops.com/findbugs"><b>FindBugs Swag</b></a></td></tr> 36 37 <tr><td> </td></tr> 38 39 <tr><td><b>Development</b></td></tr> 40 <tr><td><font size="-1"><a class="sidebar" href="http://sourceforge.net/tracker/?group_id=96405">Open bugs</a></font></td></tr> 41 <tr><td><font size="-1"><a class="sidebar" href="reportingBugs.html">Reporting bugs</a></font></td></tr> 42 <tr><td><font size="-1"><a class="sidebar" href="contributing.html">Contributing</a></font></td></tr> 43 <tr><td><font size="-1"><a class="sidebar" href="team.html">Dev team</a></font></td></tr> 44 <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> 45 <tr><td><font size="-1"><a class="sidebar" href="Changes.html">Change log</a></font></td></tr> 46 <tr><td><font size="-1"><a class="sidebar" href="http://sourceforge.net/projects/findbugs">SF project page</a></font></td></tr> 47 <tr><td><font size="-1"><a class="sidebar" href="http://code.google.com/p/findbugs/source/browse/">Browse source</a></font></td></tr> 48 <tr><td><font size="-1"><a class="sidebar" href="http://code.google.com/p/findbugs/source/list">Latest code changes</a></font></td></tr> 49 </table> 50 </td> 51 <td align="left" valign="top"> 52 <h1>FindBugs Bug Descriptions</h1> 53 <p>This document lists the standard bug patterns reported by 54 <a href="http://findbugs.sourceforge.net">FindBugs</a> version 2.0.3.</p> 55 <h2>Summary</h2> 56 <table width="100%"> 57 <tr bgcolor="#b9b9fe"><th>Description</th><th>Category</th></tr> 58 <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> 59 <tr bgcolor="#ffffff"><td><a href="#BIT_SIGNED_CHECK">BIT: Check for sign of bitwise operation</a></td><td>Bad practice</td></tr> 60 <tr bgcolor="#eeeeee"><td><a href="#CN_IDIOM">CN: Class implements Cloneable but does not define or use clone method</a></td><td>Bad practice</td></tr> 61 <tr bgcolor="#ffffff"><td><a href="#CN_IDIOM_NO_SUPER_CALL">CN: clone method does not call super.clone()</a></td><td>Bad practice</td></tr> 62 <tr bgcolor="#eeeeee"><td><a href="#CN_IMPLEMENTS_CLONE_BUT_NOT_CLONEABLE">CN: Class defines clone() but doesn't implement Cloneable</a></td><td>Bad practice</td></tr> 63 <tr bgcolor="#ffffff"><td><a href="#CO_ABSTRACT_SELF">Co: Abstract class defines covariant compareTo() method</a></td><td>Bad practice</td></tr> 64 <tr bgcolor="#eeeeee"><td><a href="#CO_SELF_NO_OBJECT">Co: Covariant compareTo() method defined</a></td><td>Bad practice</td></tr> 65 <tr bgcolor="#ffffff"><td><a href="#DE_MIGHT_DROP">DE: Method might drop exception</a></td><td>Bad practice</td></tr> 66 <tr bgcolor="#eeeeee"><td><a href="#DE_MIGHT_IGNORE">DE: Method might ignore exception</a></td><td>Bad practice</td></tr> 67 <tr bgcolor="#ffffff"><td><a href="#DMI_ENTRY_SETS_MAY_REUSE_ENTRY_OBJECTS">DMI: Adding elements of an entry set may fail due to reuse of Entry objects</a></td><td>Bad practice</td></tr> 68 <tr bgcolor="#eeeeee"><td><a href="#DMI_RANDOM_USED_ONLY_ONCE">DMI: Random object created and used only once</a></td><td>Bad practice</td></tr> 69 <tr bgcolor="#ffffff"><td><a href="#DMI_USING_REMOVEALL_TO_CLEAR_COLLECTION">DMI: Don't use removeAll to clear a collection</a></td><td>Bad practice</td></tr> 70 <tr bgcolor="#eeeeee"><td><a href="#DM_EXIT">Dm: Method invokes System.exit(...)</a></td><td>Bad practice</td></tr> 71 <tr bgcolor="#ffffff"><td><a href="#DM_RUN_FINALIZERS_ON_EXIT">Dm: Method invokes dangerous method runFinalizersOnExit</a></td><td>Bad practice</td></tr> 72 <tr bgcolor="#eeeeee"><td><a href="#ES_COMPARING_PARAMETER_STRING_WITH_EQ">ES: Comparison of String parameter using == or !=</a></td><td>Bad practice</td></tr> 73 <tr bgcolor="#ffffff"><td><a href="#ES_COMPARING_STRINGS_WITH_EQ">ES: Comparison of String objects using == or !=</a></td><td>Bad practice</td></tr> 74 <tr bgcolor="#eeeeee"><td><a href="#EQ_ABSTRACT_SELF">Eq: Abstract class defines covariant equals() method</a></td><td>Bad practice</td></tr> 75 <tr bgcolor="#ffffff"><td><a href="#EQ_CHECK_FOR_OPERAND_NOT_COMPATIBLE_WITH_THIS">Eq: Equals checks for incompatible operand</a></td><td>Bad practice</td></tr> 76 <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> 77 <tr bgcolor="#ffffff"><td><a href="#EQ_GETCLASS_AND_CLASS_CONSTANT">Eq: equals method fails for subtypes</a></td><td>Bad practice</td></tr> 78 <tr bgcolor="#eeeeee"><td><a href="#EQ_SELF_NO_OBJECT">Eq: Covariant equals() method defined</a></td><td>Bad practice</td></tr> 79 <tr bgcolor="#ffffff"><td><a href="#FI_EMPTY">FI: Empty finalizer should be deleted</a></td><td>Bad practice</td></tr> 80 <tr bgcolor="#eeeeee"><td><a href="#FI_EXPLICIT_INVOCATION">FI: Explicit invocation of finalizer</a></td><td>Bad practice</td></tr> 81 <tr bgcolor="#ffffff"><td><a href="#FI_FINALIZER_NULLS_FIELDS">FI: Finalizer nulls fields</a></td><td>Bad practice</td></tr> 82 <tr bgcolor="#eeeeee"><td><a href="#FI_FINALIZER_ONLY_NULLS_FIELDS">FI: Finalizer only nulls fields</a></td><td>Bad practice</td></tr> 83 <tr bgcolor="#ffffff"><td><a href="#FI_MISSING_SUPER_CALL">FI: Finalizer does not call superclass finalizer</a></td><td>Bad practice</td></tr> 84 <tr bgcolor="#eeeeee"><td><a href="#FI_NULLIFY_SUPER">FI: Finalizer nullifies superclass finalizer</a></td><td>Bad practice</td></tr> 85 <tr bgcolor="#ffffff"><td><a href="#FI_USELESS">FI: Finalizer does nothing but call superclass finalizer</a></td><td>Bad practice</td></tr> 86 <tr bgcolor="#eeeeee"><td><a href="#VA_FORMAT_STRING_USES_NEWLINE">FS: Format string should use %n rather than \n</a></td><td>Bad practice</td></tr> 87 <tr bgcolor="#ffffff"><td><a href="#GC_UNCHECKED_TYPE_IN_GENERIC_CALL">GC: Unchecked type in generic call</a></td><td>Bad practice</td></tr> 88 <tr bgcolor="#eeeeee"><td><a href="#HE_EQUALS_NO_HASHCODE">HE: Class defines equals() but not hashCode()</a></td><td>Bad practice</td></tr> 89 <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> 90 <tr bgcolor="#eeeeee"><td><a href="#HE_HASHCODE_NO_EQUALS">HE: Class defines hashCode() but not equals()</a></td><td>Bad practice</td></tr> 91 <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> 92 <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> 93 <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> 94 <tr bgcolor="#eeeeee"><td><a href="#IMSE_DONT_CATCH_IMSE">IMSE: Dubious catching of IllegalMonitorStateException</a></td><td>Bad practice</td></tr> 95 <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> 96 <tr bgcolor="#eeeeee"><td><a href="#IT_NO_SUCH_ELEMENT">It: Iterator next() method can't throw NoSuchElementException</a></td><td>Bad practice</td></tr> 97 <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> 98 <tr bgcolor="#eeeeee"><td><a href="#JCIP_FIELD_ISNT_FINAL_IN_IMMUTABLE_CLASS">JCIP: Fields of immutable classes should be final</a></td><td>Bad practice</td></tr> 99 <tr bgcolor="#ffffff"><td><a href="#NP_BOOLEAN_RETURN_NULL">NP: Method with Boolean return type returns explicit null</a></td><td>Bad practice</td></tr> 100 <tr bgcolor="#eeeeee"><td><a href="#NP_CLONE_COULD_RETURN_NULL">NP: Clone method may return null</a></td><td>Bad practice</td></tr> 101 <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> 102 <tr bgcolor="#eeeeee"><td><a href="#NP_TOSTRING_COULD_RETURN_NULL">NP: toString method may return null</a></td><td>Bad practice</td></tr> 103 <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> 104 <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> 105 <tr bgcolor="#ffffff"><td><a href="#NM_CONFUSING">Nm: Confusing method names</a></td><td>Bad practice</td></tr> 106 <tr bgcolor="#eeeeee"><td><a href="#NM_FIELD_NAMING_CONVENTION">Nm: Field names should start with a lower case letter</a></td><td>Bad practice</td></tr> 107 <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> 108 <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> 109 <tr bgcolor="#ffffff"><td><a href="#NM_METHOD_NAMING_CONVENTION">Nm: Method names should start with a lower case letter</a></td><td>Bad practice</td></tr> 110 <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> 111 <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> 112 <tr bgcolor="#eeeeee"><td><a href="#NM_VERY_CONFUSING_INTENTIONAL">Nm: Very confusing method names (but perhaps intentional)</a></td><td>Bad practice</td></tr> 113 <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> 114 <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> 115 <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> 116 <tr bgcolor="#eeeeee"><td><a href="#OS_OPEN_STREAM">OS: Method may fail to close stream</a></td><td>Bad practice</td></tr> 117 <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> 118 <tr bgcolor="#eeeeee"><td><a href="#PZ_DONT_REUSE_ENTRY_OBJECTS_IN_ITERATORS">PZ: Don't reuse entry objects in iterators</a></td><td>Bad practice</td></tr> 119 <tr bgcolor="#ffffff"><td><a href="#RC_REF_COMPARISON_BAD_PRACTICE">RC: Suspicious reference comparison to constant</a></td><td>Bad practice</td></tr> 120 <tr bgcolor="#eeeeee"><td><a href="#RC_REF_COMPARISON_BAD_PRACTICE_BOOLEAN">RC: Suspicious reference comparison of Boolean values</a></td><td>Bad practice</td></tr> 121 <tr bgcolor="#ffffff"><td><a href="#RR_NOT_CHECKED">RR: Method ignores results of InputStream.read()</a></td><td>Bad practice</td></tr> 122 <tr bgcolor="#eeeeee"><td><a href="#SR_NOT_CHECKED">RR: Method ignores results of InputStream.skip()</a></td><td>Bad practice</td></tr> 123 <tr bgcolor="#ffffff"><td><a href="#RV_NEGATING_RESULT_OF_COMPARETO">RV: Negating the result of compareTo()/compare()</a></td><td>Bad practice</td></tr> 124 <tr bgcolor="#eeeeee"><td><a href="#RV_RETURN_VALUE_IGNORED_BAD_PRACTICE">RV: Method ignores exceptional return value</a></td><td>Bad practice</td></tr> 125 <tr bgcolor="#ffffff"><td><a href="#SI_INSTANCE_BEFORE_FINALS_ASSIGNED">SI: Static initializer creates instance before all static final fields assigned</a></td><td>Bad practice</td></tr> 126 <tr bgcolor="#eeeeee"><td><a href="#SW_SWING_METHODS_INVOKED_IN_SWING_THREAD">SW: Certain swing methods needs to be invoked in Swing thread</a></td><td>Bad practice</td></tr> 127 <tr bgcolor="#ffffff"><td><a href="#SE_BAD_FIELD">Se: Non-transient non-serializable instance field in serializable class</a></td><td>Bad practice</td></tr> 128 <tr bgcolor="#eeeeee"><td><a href="#SE_BAD_FIELD_INNER_CLASS">Se: Non-serializable class has a serializable inner class</a></td><td>Bad practice</td></tr> 129 <tr bgcolor="#ffffff"><td><a href="#SE_BAD_FIELD_STORE">Se: Non-serializable value stored into instance field of a serializable class</a></td><td>Bad practice</td></tr> 130 <tr bgcolor="#eeeeee"><td><a href="#SE_COMPARATOR_SHOULD_BE_SERIALIZABLE">Se: Comparator doesn't implement Serializable</a></td><td>Bad practice</td></tr> 131 <tr bgcolor="#ffffff"><td><a href="#SE_INNER_CLASS">Se: Serializable inner class</a></td><td>Bad practice</td></tr> 132 <tr bgcolor="#eeeeee"><td><a href="#SE_NONFINAL_SERIALVERSIONID">Se: serialVersionUID isn't final</a></td><td>Bad practice</td></tr> 133 <tr bgcolor="#ffffff"><td><a href="#SE_NONLONG_SERIALVERSIONID">Se: serialVersionUID isn't long</a></td><td>Bad practice</td></tr> 134 <tr bgcolor="#eeeeee"><td><a href="#SE_NONSTATIC_SERIALVERSIONID">Se: serialVersionUID isn't static</a></td><td>Bad practice</td></tr> 135 <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> 136 <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> 137 <tr bgcolor="#ffffff"><td><a href="#SE_READ_RESOLVE_MUST_RETURN_OBJECT">Se: The readResolve method must be declared with a return type of Object. </a></td><td>Bad practice</td></tr> 138 <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> 139 <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> 140 <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> 141 <tr bgcolor="#ffffff"><td><a href="#BC_IMPOSSIBLE_CAST">BC: Impossible cast</a></td><td>Correctness</td></tr> 142 <tr bgcolor="#eeeeee"><td><a href="#BC_IMPOSSIBLE_DOWNCAST">BC: Impossible downcast</a></td><td>Correctness</td></tr> 143 <tr bgcolor="#ffffff"><td><a href="#BC_IMPOSSIBLE_DOWNCAST_OF_TOARRAY">BC: Impossible downcast of toArray() result</a></td><td>Correctness</td></tr> 144 <tr bgcolor="#eeeeee"><td><a href="#BC_IMPOSSIBLE_INSTANCEOF">BC: instanceof will always return false</a></td><td>Correctness</td></tr> 145 <tr bgcolor="#ffffff"><td><a href="#BIT_ADD_OF_SIGNED_BYTE">BIT: Bitwise add of signed byte value</a></td><td>Correctness</td></tr> 146 <tr bgcolor="#eeeeee"><td><a href="#BIT_AND">BIT: Incompatible bit masks</a></td><td>Correctness</td></tr> 147 <tr bgcolor="#ffffff"><td><a href="#BIT_AND_ZZ">BIT: Check to see if ((...) & 0) == 0</a></td><td>Correctness</td></tr> 148 <tr bgcolor="#eeeeee"><td><a href="#BIT_IOR">BIT: Incompatible bit masks</a></td><td>Correctness</td></tr> 149 <tr bgcolor="#ffffff"><td><a href="#BIT_IOR_OF_SIGNED_BYTE">BIT: Bitwise OR of signed byte value</a></td><td>Correctness</td></tr> 150 <tr bgcolor="#eeeeee"><td><a href="#BIT_SIGNED_CHECK_HIGH_BIT">BIT: Check for sign of bitwise operation</a></td><td>Correctness</td></tr> 151 <tr bgcolor="#ffffff"><td><a href="#BOA_BADLY_OVERRIDDEN_ADAPTER">BOA: Class overrides a method implemented in super class Adapter wrongly</a></td><td>Correctness</td></tr> 152 <tr bgcolor="#eeeeee"><td><a href="#ICAST_BAD_SHIFT_AMOUNT">BSHIFT: 32 bit int shifted by an amount not in the range -31..31</a></td><td>Correctness</td></tr> 153 <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> 154 <tr bgcolor="#eeeeee"><td><a href="#CO_COMPARETO_RESULTS_MIN_VALUE">Co: compareTo()/compare() returns Integer.MIN_VALUE</a></td><td>Correctness</td></tr> 155 <tr bgcolor="#ffffff"><td><a href="#DLS_DEAD_LOCAL_INCREMENT_IN_RETURN">DLS: Useless increment in return statement</a></td><td>Correctness</td></tr> 156 <tr bgcolor="#eeeeee"><td><a href="#DLS_DEAD_STORE_OF_CLASS_LITERAL">DLS: Dead store of class literal</a></td><td>Correctness</td></tr> 157 <tr bgcolor="#ffffff"><td><a href="#DLS_OVERWRITTEN_INCREMENT">DLS: Overwritten increment</a></td><td>Correctness</td></tr> 158 <tr bgcolor="#eeeeee"><td><a href="#DMI_ARGUMENTS_WRONG_ORDER">DMI: Reversed method arguments</a></td><td>Correctness</td></tr> 159 <tr bgcolor="#ffffff"><td><a href="#DMI_BAD_MONTH">DMI: Bad constant value for month</a></td><td>Correctness</td></tr> 160 <tr bgcolor="#eeeeee"><td><a href="#DMI_BIGDECIMAL_CONSTRUCTED_FROM_DOUBLE">DMI: BigDecimal constructed from double that isn't represented precisely</a></td><td>Correctness</td></tr> 161 <tr bgcolor="#ffffff"><td><a href="#DMI_CALLING_NEXT_FROM_HASNEXT">DMI: hasNext method invokes next</a></td><td>Correctness</td></tr> 162 <tr bgcolor="#eeeeee"><td><a href="#DMI_COLLECTIONS_SHOULD_NOT_CONTAIN_THEMSELVES">DMI: Collections should not contain themselves</a></td><td>Correctness</td></tr> 163 <tr bgcolor="#ffffff"><td><a href="#DMI_DOH">DMI: D'oh! A nonsensical method invocation</a></td><td>Correctness</td></tr> 164 <tr bgcolor="#eeeeee"><td><a href="#DMI_INVOKING_HASHCODE_ON_ARRAY">DMI: Invocation of hashCode on an array</a></td><td>Correctness</td></tr> 165 <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> 166 <tr bgcolor="#eeeeee"><td><a href="#DMI_VACUOUS_SELF_COLLECTION_CALL">DMI: Vacuous call to collections</a></td><td>Correctness</td></tr> 167 <tr bgcolor="#ffffff"><td><a href="#DMI_ANNOTATION_IS_NOT_VISIBLE_TO_REFLECTION">Dm: Can't use reflection to check for presence of annotation without runtime retention</a></td><td>Correctness</td></tr> 168 <tr bgcolor="#eeeeee"><td><a href="#DMI_FUTILE_ATTEMPT_TO_CHANGE_MAXPOOL_SIZE_OF_SCHEDULED_THREAD_POOL_EXECUTOR">Dm: Futile attempt to change max pool size of ScheduledThreadPoolExecutor</a></td><td>Correctness</td></tr> 169 <tr bgcolor="#ffffff"><td><a href="#DMI_SCHEDULED_THREAD_POOL_EXECUTOR_WITH_ZERO_CORE_THREADS">Dm: Creation of ScheduledThreadPoolExecutor with zero core threads</a></td><td>Correctness</td></tr> 170 <tr bgcolor="#eeeeee"><td><a href="#DMI_VACUOUS_CALL_TO_EASYMOCK_METHOD">Dm: Useless/vacuous call to EasyMock method</a></td><td>Correctness</td></tr> 171 <tr bgcolor="#ffffff"><td><a href="#EC_ARRAY_AND_NONARRAY">EC: equals() used to compare array and nonarray</a></td><td>Correctness</td></tr> 172 <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> 173 <tr bgcolor="#ffffff"><td><a href="#EC_INCOMPATIBLE_ARRAY_COMPARE">EC: equals(...) used to compare incompatible arrays</a></td><td>Correctness</td></tr> 174 <tr bgcolor="#eeeeee"><td><a href="#EC_NULL_ARG">EC: Call to equals(null)</a></td><td>Correctness</td></tr> 175 <tr bgcolor="#ffffff"><td><a href="#EC_UNRELATED_CLASS_AND_INTERFACE">EC: Call to equals() comparing unrelated class and interface</a></td><td>Correctness</td></tr> 176 <tr bgcolor="#eeeeee"><td><a href="#EC_UNRELATED_INTERFACES">EC: Call to equals() comparing different interface types</a></td><td>Correctness</td></tr> 177 <tr bgcolor="#ffffff"><td><a href="#EC_UNRELATED_TYPES">EC: Call to equals() comparing different types</a></td><td>Correctness</td></tr> 178 <tr bgcolor="#eeeeee"><td><a href="#EC_UNRELATED_TYPES_USING_POINTER_EQUALITY">EC: Using pointer equality to compare different types</a></td><td>Correctness</td></tr> 179 <tr bgcolor="#ffffff"><td><a href="#EQ_ALWAYS_FALSE">Eq: equals method always returns false</a></td><td>Correctness</td></tr> 180 <tr bgcolor="#eeeeee"><td><a href="#EQ_ALWAYS_TRUE">Eq: equals method always returns true</a></td><td>Correctness</td></tr> 181 <tr bgcolor="#ffffff"><td><a href="#EQ_COMPARING_CLASS_NAMES">Eq: equals method compares class names rather than class objects</a></td><td>Correctness</td></tr> 182 <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> 183 <tr bgcolor="#ffffff"><td><a href="#EQ_OTHER_NO_OBJECT">Eq: equals() method defined that doesn't override equals(Object)</a></td><td>Correctness</td></tr> 184 <tr bgcolor="#eeeeee"><td><a href="#EQ_OTHER_USE_OBJECT">Eq: equals() method defined that doesn't override Object.equals(Object)</a></td><td>Correctness</td></tr> 185 <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> 186 <tr bgcolor="#eeeeee"><td><a href="#EQ_SELF_USE_OBJECT">Eq: Covariant equals() method defined, Object.equals(Object) inherited</a></td><td>Correctness</td></tr> 187 <tr bgcolor="#ffffff"><td><a href="#FE_TEST_IF_EQUAL_TO_NOT_A_NUMBER">FE: Doomed test for equality to NaN</a></td><td>Correctness</td></tr> 188 <tr bgcolor="#eeeeee"><td><a href="#VA_FORMAT_STRING_BAD_ARGUMENT">FS: Format string placeholder incompatible with passed argument</a></td><td>Correctness</td></tr> 189 <tr bgcolor="#ffffff"><td><a href="#VA_FORMAT_STRING_BAD_CONVERSION">FS: The type of a supplied argument doesn't match format specifier</a></td><td>Correctness</td></tr> 190 <tr bgcolor="#eeeeee"><td><a href="#VA_FORMAT_STRING_EXPECTED_MESSAGE_FORMAT_SUPPLIED">FS: MessageFormat supplied where printf style format expected</a></td><td>Correctness</td></tr> 191 <tr bgcolor="#ffffff"><td><a href="#VA_FORMAT_STRING_EXTRA_ARGUMENTS_PASSED">FS: More arguments are passed than are actually used in the format string</a></td><td>Correctness</td></tr> 192 <tr bgcolor="#eeeeee"><td><a href="#VA_FORMAT_STRING_ILLEGAL">FS: Illegal format string</a></td><td>Correctness</td></tr> 193 <tr bgcolor="#ffffff"><td><a href="#VA_FORMAT_STRING_MISSING_ARGUMENT">FS: Format string references missing argument</a></td><td>Correctness</td></tr> 194 <tr bgcolor="#eeeeee"><td><a href="#VA_FORMAT_STRING_NO_PREVIOUS_ARGUMENT">FS: No previous argument for format string</a></td><td>Correctness</td></tr> 195 <tr bgcolor="#ffffff"><td><a href="#GC_UNRELATED_TYPES">GC: No relationship between generic parameter and method argument</a></td><td>Correctness</td></tr> 196 <tr bgcolor="#eeeeee"><td><a href="#HE_SIGNATURE_DECLARES_HASHING_OF_UNHASHABLE_CLASS">HE: Signature declares use of unhashable class in hashed construct</a></td><td>Correctness</td></tr> 197 <tr bgcolor="#ffffff"><td><a href="#HE_USE_OF_UNHASHABLE_CLASS">HE: Use of class without a hashCode() method in a hashed data structure</a></td><td>Correctness</td></tr> 198 <tr bgcolor="#eeeeee"><td><a href="#ICAST_INT_2_LONG_AS_INSTANT">ICAST: int value converted to long and used as absolute time</a></td><td>Correctness</td></tr> 199 <tr bgcolor="#ffffff"><td><a href="#ICAST_INT_CAST_TO_DOUBLE_PASSED_TO_CEIL">ICAST: Integral value cast to double and then passed to Math.ceil</a></td><td>Correctness</td></tr> 200 <tr bgcolor="#eeeeee"><td><a href="#ICAST_INT_CAST_TO_FLOAT_PASSED_TO_ROUND">ICAST: int value cast to float and then passed to Math.round</a></td><td>Correctness</td></tr> 201 <tr bgcolor="#ffffff"><td><a href="#IJU_ASSERT_METHOD_INVOKED_FROM_RUN_METHOD">IJU: JUnit assertion in run method will not be noticed by JUnit</a></td><td>Correctness</td></tr> 202 <tr bgcolor="#eeeeee"><td><a href="#IJU_BAD_SUITE_METHOD">IJU: TestCase declares a bad suite method </a></td><td>Correctness</td></tr> 203 <tr bgcolor="#ffffff"><td><a href="#IJU_NO_TESTS">IJU: TestCase has no tests</a></td><td>Correctness</td></tr> 204 <tr bgcolor="#eeeeee"><td><a href="#IJU_SETUP_NO_SUPER">IJU: TestCase defines setUp that doesn't call super.setUp()</a></td><td>Correctness</td></tr> 205 <tr bgcolor="#ffffff"><td><a href="#IJU_SUITE_NOT_STATIC">IJU: TestCase implements a non-static suite method </a></td><td>Correctness</td></tr> 206 <tr bgcolor="#eeeeee"><td><a href="#IJU_TEARDOWN_NO_SUPER">IJU: TestCase defines tearDown that doesn't call super.tearDown()</a></td><td>Correctness</td></tr> 207 <tr bgcolor="#ffffff"><td><a href="#IL_CONTAINER_ADDED_TO_ITSELF">IL: A collection is added to itself</a></td><td>Correctness</td></tr> 208 <tr bgcolor="#eeeeee"><td><a href="#IL_INFINITE_LOOP">IL: An apparent infinite loop</a></td><td>Correctness</td></tr> 209 <tr bgcolor="#ffffff"><td><a href="#IL_INFINITE_RECURSIVE_LOOP">IL: An apparent infinite recursive loop</a></td><td>Correctness</td></tr> 210 <tr bgcolor="#eeeeee"><td><a href="#IM_MULTIPLYING_RESULT_OF_IREM">IM: Integer multiply of result of integer remainder</a></td><td>Correctness</td></tr> 211 <tr bgcolor="#ffffff"><td><a href="#INT_BAD_COMPARISON_WITH_INT_VALUE">INT: Bad comparison of int value with long constant</a></td><td>Correctness</td></tr> 212 <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> 213 <tr bgcolor="#ffffff"><td><a href="#INT_BAD_COMPARISON_WITH_SIGNED_BYTE">INT: Bad comparison of signed byte</a></td><td>Correctness</td></tr> 214 <tr bgcolor="#eeeeee"><td><a href="#IO_APPENDING_TO_OBJECT_OUTPUT_STREAM">IO: Doomed attempt to append to an object output stream</a></td><td>Correctness</td></tr> 215 <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> 216 <tr bgcolor="#eeeeee"><td><a href="#MF_CLASS_MASKS_FIELD">MF: Class defines field that masks a superclass field</a></td><td>Correctness</td></tr> 217 <tr bgcolor="#ffffff"><td><a href="#MF_METHOD_MASKS_FIELD">MF: Method defines a variable that obscures a field</a></td><td>Correctness</td></tr> 218 <tr bgcolor="#eeeeee"><td><a href="#NP_ALWAYS_NULL">NP: Null pointer dereference</a></td><td>Correctness</td></tr> 219 <tr bgcolor="#ffffff"><td><a href="#NP_ALWAYS_NULL_EXCEPTION">NP: Null pointer dereference in method on exception path</a></td><td>Correctness</td></tr> 220 <tr bgcolor="#eeeeee"><td><a href="#NP_ARGUMENT_MIGHT_BE_NULL">NP: Method does not check for null argument</a></td><td>Correctness</td></tr> 221 <tr bgcolor="#ffffff"><td><a href="#NP_CLOSING_NULL">NP: close() invoked on a value that is always null</a></td><td>Correctness</td></tr> 222 <tr bgcolor="#eeeeee"><td><a href="#NP_GUARANTEED_DEREF">NP: Null value is guaranteed to be dereferenced</a></td><td>Correctness</td></tr> 223 <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> 224 <tr bgcolor="#eeeeee"><td><a href="#NP_NONNULL_FIELD_NOT_INITIALIZED_IN_CONSTRUCTOR">NP: Nonnull field is not initialized</a></td><td>Correctness</td></tr> 225 <tr bgcolor="#ffffff"><td><a href="#NP_NONNULL_PARAM_VIOLATION">NP: Method call passes null to a nonnull parameter </a></td><td>Correctness</td></tr> 226 <tr bgcolor="#eeeeee"><td><a href="#NP_NONNULL_RETURN_VIOLATION">NP: Method may return null, but is declared @NonNull</a></td><td>Correctness</td></tr> 227 <tr bgcolor="#ffffff"><td><a href="#NP_NULL_INSTANCEOF">NP: A known null value is checked to see if it is an instance of a type</a></td><td>Correctness</td></tr> 228 <tr bgcolor="#eeeeee"><td><a href="#NP_NULL_ON_SOME_PATH">NP: Possible null pointer dereference</a></td><td>Correctness</td></tr> 229 <tr bgcolor="#ffffff"><td><a href="#NP_NULL_ON_SOME_PATH_EXCEPTION">NP: Possible null pointer dereference in method on exception path</a></td><td>Correctness</td></tr> 230 <tr bgcolor="#eeeeee"><td><a href="#NP_NULL_PARAM_DEREF">NP: Method call passes null for nonnull parameter</a></td><td>Correctness</td></tr> 231 <tr bgcolor="#ffffff"><td><a href="#NP_NULL_PARAM_DEREF_ALL_TARGETS_DANGEROUS">NP: Method call passes null for nonnull parameter</a></td><td>Correctness</td></tr> 232 <tr bgcolor="#eeeeee"><td><a href="#NP_NULL_PARAM_DEREF_NONVIRTUAL">NP: Non-virtual method call passes null for nonnull parameter</a></td><td>Correctness</td></tr> 233 <tr bgcolor="#ffffff"><td><a href="#NP_STORE_INTO_NONNULL_FIELD">NP: Store of null value into field annotated NonNull</a></td><td>Correctness</td></tr> 234 <tr bgcolor="#eeeeee"><td><a href="#NP_UNWRITTEN_FIELD">NP: Read of unwritten field</a></td><td>Correctness</td></tr> 235 <tr bgcolor="#ffffff"><td><a href="#NM_BAD_EQUAL">Nm: Class defines equal(Object); should it be equals(Object)?</a></td><td>Correctness</td></tr> 236 <tr bgcolor="#eeeeee"><td><a href="#NM_LCASE_HASHCODE">Nm: Class defines hashcode(); should it be hashCode()?</a></td><td>Correctness</td></tr> 237 <tr bgcolor="#ffffff"><td><a href="#NM_LCASE_TOSTRING">Nm: Class defines tostring(); should it be toString()?</a></td><td>Correctness</td></tr> 238 <tr bgcolor="#eeeeee"><td><a href="#NM_METHOD_CONSTRUCTOR_CONFUSION">Nm: Apparent method/constructor confusion</a></td><td>Correctness</td></tr> 239 <tr bgcolor="#ffffff"><td><a href="#NM_VERY_CONFUSING">Nm: Very confusing method names</a></td><td>Correctness</td></tr> 240 <tr bgcolor="#eeeeee"><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> 241 <tr bgcolor="#ffffff"><td><a href="#QBA_QUESTIONABLE_BOOLEAN_ASSIGNMENT">QBA: Method assigns boolean literal in boolean expression</a></td><td>Correctness</td></tr> 242 <tr bgcolor="#eeeeee"><td><a href="#RC_REF_COMPARISON">RC: Suspicious reference comparison</a></td><td>Correctness</td></tr> 243 <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> 244 <tr bgcolor="#eeeeee"><td><a href="#RE_BAD_SYNTAX_FOR_REGULAR_EXPRESSION">RE: Invalid syntax for regular expression</a></td><td>Correctness</td></tr> 245 <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> 246 <tr bgcolor="#eeeeee"><td><a href="#RE_POSSIBLE_UNINTENDED_PATTERN">RE: "." or "|" used for regular expression</a></td><td>Correctness</td></tr> 247 <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> 248 <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> 249 <tr bgcolor="#ffffff"><td><a href="#RV_ABSOLUTE_VALUE_OF_RANDOM_INT">RV: Bad attempt to compute absolute value of signed random integer</a></td><td>Correctness</td></tr> 250 <tr bgcolor="#eeeeee"><td><a href="#RV_CHECK_COMPARETO_FOR_SPECIFIC_RETURN_VALUE">RV: Code checks for specific values returned by compareTo</a></td><td>Correctness</td></tr> 251 <tr bgcolor="#ffffff"><td><a href="#RV_EXCEPTION_NOT_THROWN">RV: Exception created and dropped rather than thrown</a></td><td>Correctness</td></tr> 252 <tr bgcolor="#eeeeee"><td><a href="#RV_RETURN_VALUE_IGNORED">RV: Method ignores return value</a></td><td>Correctness</td></tr> 253 <tr bgcolor="#ffffff"><td><a href="#RpC_REPEATED_CONDITIONAL_TEST">RpC: Repeated conditional tests</a></td><td>Correctness</td></tr> 254 <tr bgcolor="#eeeeee"><td><a href="#SA_FIELD_SELF_ASSIGNMENT">SA: Self assignment of field</a></td><td>Correctness</td></tr> 255 <tr bgcolor="#ffffff"><td><a href="#SA_FIELD_SELF_COMPARISON">SA: Self comparison of field with itself</a></td><td>Correctness</td></tr> 256 <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> 257 <tr bgcolor="#ffffff"><td><a href="#SA_LOCAL_SELF_ASSIGNMENT_INSTEAD_OF_FIELD">SA: Self assignment of local rather than assignment to field</a></td><td>Correctness</td></tr> 258 <tr bgcolor="#eeeeee"><td><a href="#SA_LOCAL_SELF_COMPARISON">SA: Self comparison of value with itself</a></td><td>Correctness</td></tr> 259 <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> 260 <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> 261 <tr bgcolor="#ffffff"><td><a href="#SF_DEAD_STORE_DUE_TO_SWITCH_FALLTHROUGH_TO_THROW">SF: Dead store due to switch statement fall through to throw</a></td><td>Correctness</td></tr> 262 <tr bgcolor="#eeeeee"><td><a href="#SIC_THREADLOCAL_DEADLY_EMBRACE">SIC: Deadly embrace of non-static inner class and thread local</a></td><td>Correctness</td></tr> 263 <tr bgcolor="#ffffff"><td><a href="#SIO_SUPERFLUOUS_INSTANCEOF">SIO: Unnecessary type check done using instanceof operator</a></td><td>Correctness</td></tr> 264 <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> 265 <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> 266 <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> 267 <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> 268 <tr bgcolor="#eeeeee"><td><a href="#SE_METHOD_MUST_BE_PRIVATE">Se: Method must be private in order for serialization to work</a></td><td>Correctness</td></tr> 269 <tr bgcolor="#ffffff"><td><a href="#SE_READ_RESOLVE_IS_STATIC">Se: The readResolve method must not be declared as a static method. </a></td><td>Correctness</td></tr> 270 <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> 271 <tr bgcolor="#ffffff"><td><a href="#TQ_COMPARING_VALUES_WITH_INCOMPATIBLE_TYPE_QUALIFIERS">TQ: Comparing values with incompatible type qualifiers</a></td><td>Correctness</td></tr> 272 <tr bgcolor="#eeeeee"><td><a href="#TQ_MAYBE_SOURCE_VALUE_REACHES_ALWAYS_SINK">TQ: Value that might not carry a type qualifier is always used in a way requires that type qualifier</a></td><td>Correctness</td></tr> 273 <tr bgcolor="#ffffff"><td><a href="#TQ_MAYBE_SOURCE_VALUE_REACHES_NEVER_SINK">TQ: Value that might carry a type qualifier is always used in a way prohibits it from having that type qualifier</a></td><td>Correctness</td></tr> 274 <tr bgcolor="#eeeeee"><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> 275 <tr bgcolor="#ffffff"><td><a href="#TQ_UNKNOWN_VALUE_USED_WHERE_ALWAYS_STRICTLY_REQUIRED">TQ: Value without a type qualifier used where a value is required to have that qualifier</a></td><td>Correctness</td></tr> 276 <tr bgcolor="#eeeeee"><td><a href="#UMAC_UNCALLABLE_METHOD_OF_ANONYMOUS_CLASS">UMAC: Uncallable method defined in anonymous class</a></td><td>Correctness</td></tr> 277 <tr bgcolor="#ffffff"><td><a href="#UR_UNINIT_READ">UR: Uninitialized read of field in constructor</a></td><td>Correctness</td></tr> 278 <tr bgcolor="#eeeeee"><td><a href="#UR_UNINIT_READ_CALLED_FROM_SUPER_CONSTRUCTOR">UR: Uninitialized read of field method called from constructor of superclass</a></td><td>Correctness</td></tr> 279 <tr bgcolor="#ffffff"><td><a href="#DMI_INVOKING_TOSTRING_ON_ANONYMOUS_ARRAY">USELESS_STRING: Invocation of toString on an unnamed array</a></td><td>Correctness</td></tr> 280 <tr bgcolor="#eeeeee"><td><a href="#DMI_INVOKING_TOSTRING_ON_ARRAY">USELESS_STRING: Invocation of toString on an array</a></td><td>Correctness</td></tr> 281 <tr bgcolor="#ffffff"><td><a href="#VA_FORMAT_STRING_BAD_CONVERSION_FROM_ARRAY">USELESS_STRING: Array formatted in useless way using format string</a></td><td>Correctness</td></tr> 282 <tr bgcolor="#eeeeee"><td><a href="#UWF_NULL_FIELD">UwF: Field only ever set to null</a></td><td>Correctness</td></tr> 283 <tr bgcolor="#ffffff"><td><a href="#UWF_UNWRITTEN_FIELD">UwF: Unwritten field</a></td><td>Correctness</td></tr> 284 <tr bgcolor="#eeeeee"><td><a href="#VA_PRIMITIVE_ARRAY_PASSED_TO_OBJECT_VARARG">VA: Primitive array passed to function expecting a variable number of object arguments</a></td><td>Correctness</td></tr> 285 <tr bgcolor="#ffffff"><td><a href="#LG_LOST_LOGGER_DUE_TO_WEAK_REFERENCE">LG: Potential lost logger changes due to weak reference in OpenJDK</a></td><td>Experimental</td></tr> 286 <tr bgcolor="#eeeeee"><td><a href="#OBL_UNSATISFIED_OBLIGATION">OBL: Method may fail to clean up stream or resource</a></td><td>Experimental</td></tr> 287 <tr bgcolor="#ffffff"><td><a href="#OBL_UNSATISFIED_OBLIGATION_EXCEPTION_EDGE">OBL: Method may fail to clean up stream or resource on checked exception</a></td><td>Experimental</td></tr> 288 <tr bgcolor="#eeeeee"><td><a href="#DM_CONVERT_CASE">Dm: Consider using Locale parameterized version of invoked method</a></td><td>Internationalization</td></tr> 289 <tr bgcolor="#ffffff"><td><a href="#DM_DEFAULT_ENCODING">Dm: Reliance on default encoding</a></td><td>Internationalization</td></tr> 290 <tr bgcolor="#eeeeee"><td><a href="#DP_CREATE_CLASSLOADER_INSIDE_DO_PRIVILEGED">DP: Classloaders should only be created inside doPrivileged block</a></td><td>Malicious code vulnerability</td></tr> 291 <tr bgcolor="#ffffff"><td><a href="#DP_DO_INSIDE_DO_PRIVILEGED">DP: Method invoked that should be only be invoked inside a doPrivileged block</a></td><td>Malicious code vulnerability</td></tr> 292 <tr bgcolor="#eeeeee"><td><a href="#EI_EXPOSE_REP">EI: May expose internal representation by returning reference to mutable object</a></td><td>Malicious code vulnerability</td></tr> 293 <tr bgcolor="#ffffff"><td><a href="#EI_EXPOSE_REP2">EI2: May expose internal representation by incorporating reference to mutable object</a></td><td>Malicious code vulnerability</td></tr> 294 <tr bgcolor="#eeeeee"><td><a href="#FI_PUBLIC_SHOULD_BE_PROTECTED">FI: Finalizer should be protected, not public</a></td><td>Malicious code vulnerability</td></tr> 295 <tr bgcolor="#ffffff"><td><a href="#EI_EXPOSE_STATIC_REP2">MS: May expose internal static state by storing a mutable object into a static field</a></td><td>Malicious code vulnerability</td></tr> 296 <tr bgcolor="#eeeeee"><td><a href="#MS_CANNOT_BE_FINAL">MS: Field isn't final and can't be protected from malicious code</a></td><td>Malicious code vulnerability</td></tr> 297 <tr bgcolor="#ffffff"><td><a href="#MS_EXPOSE_REP">MS: Public static method may expose internal representation by returning array</a></td><td>Malicious code vulnerability</td></tr> 298 <tr bgcolor="#eeeeee"><td><a href="#MS_FINAL_PKGPROTECT">MS: Field should be both final and package protected</a></td><td>Malicious code vulnerability</td></tr> 299 <tr bgcolor="#ffffff"><td><a href="#MS_MUTABLE_ARRAY">MS: Field is a mutable array</a></td><td>Malicious code vulnerability</td></tr> 300 <tr bgcolor="#eeeeee"><td><a href="#MS_MUTABLE_HASHTABLE">MS: Field is a mutable Hashtable</a></td><td>Malicious code vulnerability</td></tr> 301 <tr bgcolor="#ffffff"><td><a href="#MS_OOI_PKGPROTECT">MS: Field should be moved out of an interface and made package protected</a></td><td>Malicious code vulnerability</td></tr> 302 <tr bgcolor="#eeeeee"><td><a href="#MS_PKGPROTECT">MS: Field should be package protected</a></td><td>Malicious code vulnerability</td></tr> 303 <tr bgcolor="#ffffff"><td><a href="#MS_SHOULD_BE_FINAL">MS: Field isn't final but should be</a></td><td>Malicious code vulnerability</td></tr> 304 <tr bgcolor="#eeeeee"><td><a href="#MS_SHOULD_BE_REFACTORED_TO_BE_FINAL">MS: Field isn't final but should be refactored to be so</a></td><td>Malicious code vulnerability</td></tr> 305 <tr bgcolor="#ffffff"><td><a href="#AT_OPERATION_SEQUENCE_ON_CONCURRENT_ABSTRACTION">AT: Sequence of calls to concurrent abstraction may not be atomic</a></td><td>Multithreaded correctness</td></tr> 306 <tr bgcolor="#eeeeee"><td><a href="#DC_DOUBLECHECK">DC: Possible double check of field</a></td><td>Multithreaded correctness</td></tr> 307 <tr bgcolor="#ffffff"><td><a href="#DL_SYNCHRONIZATION_ON_BOOLEAN">DL: Synchronization on Boolean</a></td><td>Multithreaded correctness</td></tr> 308 <tr bgcolor="#eeeeee"><td><a href="#DL_SYNCHRONIZATION_ON_BOXED_PRIMITIVE">DL: Synchronization on boxed primitive</a></td><td>Multithreaded correctness</td></tr> 309 <tr bgcolor="#ffffff"><td><a href="#DL_SYNCHRONIZATION_ON_SHARED_CONSTANT">DL: Synchronization on interned String </a></td><td>Multithreaded correctness</td></tr> 310 <tr bgcolor="#eeeeee"><td><a href="#DL_SYNCHRONIZATION_ON_UNSHARED_BOXED_PRIMITIVE">DL: Synchronization on boxed primitive values</a></td><td>Multithreaded correctness</td></tr> 311 <tr bgcolor="#ffffff"><td><a href="#DM_MONITOR_WAIT_ON_CONDITION">Dm: Monitor wait() called on Condition</a></td><td>Multithreaded correctness</td></tr> 312 <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> 313 <tr bgcolor="#ffffff"><td><a href="#ESync_EMPTY_SYNC">ESync: Empty synchronized block</a></td><td>Multithreaded correctness</td></tr> 314 <tr bgcolor="#eeeeee"><td><a href="#IS2_INCONSISTENT_SYNC">IS: Inconsistent synchronization</a></td><td>Multithreaded correctness</td></tr> 315 <tr bgcolor="#ffffff"><td><a href="#IS_FIELD_NOT_GUARDED">IS: Field not guarded against concurrent access</a></td><td>Multithreaded correctness</td></tr> 316 <tr bgcolor="#eeeeee"><td><a href="#JLM_JSR166_LOCK_MONITORENTER">JLM: Synchronization performed on Lock</a></td><td>Multithreaded correctness</td></tr> 317 <tr bgcolor="#ffffff"><td><a href="#JLM_JSR166_UTILCONCURRENT_MONITORENTER">JLM: Synchronization performed on util.concurrent instance</a></td><td>Multithreaded correctness</td></tr> 318 <tr bgcolor="#eeeeee"><td><a href="#JML_JSR166_CALLING_WAIT_RATHER_THAN_AWAIT">JLM: Using monitor style wait methods on util.concurrent abstraction</a></td><td>Multithreaded correctness</td></tr> 319 <tr bgcolor="#ffffff"><td><a href="#LI_LAZY_INIT_STATIC">LI: Incorrect lazy initialization of static field</a></td><td>Multithreaded correctness</td></tr> 320 <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> 321 <tr bgcolor="#ffffff"><td><a href="#ML_SYNC_ON_FIELD_TO_GUARD_CHANGING_THAT_FIELD">ML: Synchronization on field in futile attempt to guard that field</a></td><td>Multithreaded correctness</td></tr> 322 <tr bgcolor="#eeeeee"><td><a href="#ML_SYNC_ON_UPDATED_FIELD">ML: Method synchronizes on an updated field</a></td><td>Multithreaded correctness</td></tr> 323 <tr bgcolor="#ffffff"><td><a href="#MSF_MUTABLE_SERVLET_FIELD">MSF: Mutable servlet field</a></td><td>Multithreaded correctness</td></tr> 324 <tr bgcolor="#eeeeee"><td><a href="#MWN_MISMATCHED_NOTIFY">MWN: Mismatched notify()</a></td><td>Multithreaded correctness</td></tr> 325 <tr bgcolor="#ffffff"><td><a href="#MWN_MISMATCHED_WAIT">MWN: Mismatched wait()</a></td><td>Multithreaded correctness</td></tr> 326 <tr bgcolor="#eeeeee"><td><a href="#NN_NAKED_NOTIFY">NN: Naked notify</a></td><td>Multithreaded correctness</td></tr> 327 <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> 328 <tr bgcolor="#eeeeee"><td><a href="#NO_NOTIFY_NOT_NOTIFYALL">No: Using notify() rather than notifyAll()</a></td><td>Multithreaded correctness</td></tr> 329 <tr bgcolor="#ffffff"><td><a href="#RS_READOBJECT_SYNC">RS: Class's readObject() method is synchronized</a></td><td>Multithreaded correctness</td></tr> 330 <tr bgcolor="#eeeeee"><td><a href="#RV_RETURN_VALUE_OF_PUTIFABSENT_IGNORED">RV: Return value of putIfAbsent ignored, value passed to putIfAbsent reused</a></td><td>Multithreaded correctness</td></tr> 331 <tr bgcolor="#ffffff"><td><a href="#RU_INVOKE_RUN">Ru: Invokes run on a thread (did you mean to start it instead?)</a></td><td>Multithreaded correctness</td></tr> 332 <tr bgcolor="#eeeeee"><td><a href="#SC_START_IN_CTOR">SC: Constructor invokes Thread.start()</a></td><td>Multithreaded correctness</td></tr> 333 <tr bgcolor="#ffffff"><td><a href="#SP_SPIN_ON_FIELD">SP: Method spins on field</a></td><td>Multithreaded correctness</td></tr> 334 <tr bgcolor="#eeeeee"><td><a href="#STCAL_INVOKE_ON_STATIC_CALENDAR_INSTANCE">STCAL: Call to static Calendar</a></td><td>Multithreaded correctness</td></tr> 335 <tr bgcolor="#ffffff"><td><a href="#STCAL_INVOKE_ON_STATIC_DATE_FORMAT_INSTANCE">STCAL: Call to static DateFormat</a></td><td>Multithreaded correctness</td></tr> 336 <tr bgcolor="#eeeeee"><td><a href="#STCAL_STATIC_CALENDAR_INSTANCE">STCAL: Static Calendar field</a></td><td>Multithreaded correctness</td></tr> 337 <tr bgcolor="#ffffff"><td><a href="#STCAL_STATIC_SIMPLE_DATE_FORMAT_INSTANCE">STCAL: Static DateFormat</a></td><td>Multithreaded correctness</td></tr> 338 <tr bgcolor="#eeeeee"><td><a href="#SWL_SLEEP_WITH_LOCK_HELD">SWL: Method calls Thread.sleep() with a lock held</a></td><td>Multithreaded correctness</td></tr> 339 <tr bgcolor="#ffffff"><td><a href="#TLW_TWO_LOCK_WAIT">TLW: Wait with two locks held</a></td><td>Multithreaded correctness</td></tr> 340 <tr bgcolor="#eeeeee"><td><a href="#UG_SYNC_SET_UNSYNC_GET">UG: Unsynchronized get method, synchronized set method</a></td><td>Multithreaded correctness</td></tr> 341 <tr bgcolor="#ffffff"><td><a href="#UL_UNRELEASED_LOCK">UL: Method does not release lock on all paths</a></td><td>Multithreaded correctness</td></tr> 342 <tr bgcolor="#eeeeee"><td><a href="#UL_UNRELEASED_LOCK_EXCEPTION_PATH">UL: Method does not release lock on all exception paths</a></td><td>Multithreaded correctness</td></tr> 343 <tr bgcolor="#ffffff"><td><a href="#UW_UNCOND_WAIT">UW: Unconditional wait</a></td><td>Multithreaded correctness</td></tr> 344 <tr bgcolor="#eeeeee"><td><a href="#VO_VOLATILE_INCREMENT">VO: An increment to a volatile field isn't atomic</a></td><td>Multithreaded correctness</td></tr> 345 <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> 346 <tr bgcolor="#eeeeee"><td><a href="#WL_USING_GETCLASS_RATHER_THAN_CLASS_LITERAL">WL: Synchronization on getClass rather than class literal</a></td><td>Multithreaded correctness</td></tr> 347 <tr bgcolor="#ffffff"><td><a href="#WS_WRITEOBJECT_SYNC">WS: Class's writeObject() method is synchronized but nothing else is</a></td><td>Multithreaded correctness</td></tr> 348 <tr bgcolor="#eeeeee"><td><a href="#WA_AWAIT_NOT_IN_LOOP">Wa: Condition.await() not in loop </a></td><td>Multithreaded correctness</td></tr> 349 <tr bgcolor="#ffffff"><td><a href="#WA_NOT_IN_LOOP">Wa: Wait not in loop </a></td><td>Multithreaded correctness</td></tr> 350 <tr bgcolor="#eeeeee"><td><a href="#BX_BOXING_IMMEDIATELY_UNBOXED">Bx: Primitive value is boxed and then immediately unboxed</a></td><td>Performance</td></tr> 351 <tr bgcolor="#ffffff"><td><a href="#BX_BOXING_IMMEDIATELY_UNBOXED_TO_PERFORM_COERCION">Bx: Primitive value is boxed then unboxed to perform primitive coercion</a></td><td>Performance</td></tr> 352 <tr bgcolor="#eeeeee"><td><a href="#BX_UNBOXING_IMMEDIATELY_REBOXED">Bx: Boxed value is unboxed and then immediately reboxed</a></td><td>Performance</td></tr> 353 <tr bgcolor="#ffffff"><td><a href="#DM_BOXED_PRIMITIVE_FOR_PARSING">Bx: Boxing/unboxing to parse a primitive</a></td><td>Performance</td></tr> 354 <tr bgcolor="#eeeeee"><td><a href="#DM_BOXED_PRIMITIVE_TOSTRING">Bx: Method allocates a boxed primitive just to call toString</a></td><td>Performance</td></tr> 355 <tr bgcolor="#ffffff"><td><a href="#DM_FP_NUMBER_CTOR">Bx: Method invokes inefficient floating-point Number constructor; use static valueOf instead</a></td><td>Performance</td></tr> 356 <tr bgcolor="#eeeeee"><td><a href="#DM_NUMBER_CTOR">Bx: Method invokes inefficient Number constructor; use static valueOf instead</a></td><td>Performance</td></tr> 357 <tr bgcolor="#ffffff"><td><a href="#DMI_BLOCKING_METHODS_ON_URL">Dm: The equals and hashCode methods of URL are blocking</a></td><td>Performance</td></tr> 358 <tr bgcolor="#eeeeee"><td><a href="#DMI_COLLECTION_OF_URLS">Dm: Maps and sets of URLs can be performance hogs</a></td><td>Performance</td></tr> 359 <tr bgcolor="#ffffff"><td><a href="#DM_BOOLEAN_CTOR">Dm: Method invokes inefficient Boolean constructor; use Boolean.valueOf(...) instead</a></td><td>Performance</td></tr> 360 <tr bgcolor="#eeeeee"><td><a href="#DM_GC">Dm: Explicit garbage collection; extremely dubious except in benchmarking code</a></td><td>Performance</td></tr> 361 <tr bgcolor="#ffffff"><td><a href="#DM_NEW_FOR_GETCLASS">Dm: Method allocates an object, only to get the class object</a></td><td>Performance</td></tr> 362 <tr bgcolor="#eeeeee"><td><a href="#DM_NEXTINT_VIA_NEXTDOUBLE">Dm: Use the nextInt method of Random rather than nextDouble to generate a random integer</a></td><td>Performance</td></tr> 363 <tr bgcolor="#ffffff"><td><a href="#DM_STRING_CTOR">Dm: Method invokes inefficient new String(String) constructor</a></td><td>Performance</td></tr> 364 <tr bgcolor="#eeeeee"><td><a href="#DM_STRING_TOSTRING">Dm: Method invokes toString() method on a String</a></td><td>Performance</td></tr> 365 <tr bgcolor="#ffffff"><td><a href="#DM_STRING_VOID_CTOR">Dm: Method invokes inefficient new String() constructor</a></td><td>Performance</td></tr> 366 <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> 367 <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> 368 <tr bgcolor="#eeeeee"><td><a href="#SBSC_USE_STRINGBUFFER_CONCATENATION">SBSC: Method concatenates strings using + in a loop</a></td><td>Performance</td></tr> 369 <tr bgcolor="#ffffff"><td><a href="#SIC_INNER_SHOULD_BE_STATIC">SIC: Should be a static inner class</a></td><td>Performance</td></tr> 370 <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> 371 <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> 372 <tr bgcolor="#eeeeee"><td><a href="#SS_SHOULD_BE_STATIC">SS: Unread field: should this field be static?</a></td><td>Performance</td></tr> 373 <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> 374 <tr bgcolor="#eeeeee"><td><a href="#UPM_UNCALLED_PRIVATE_METHOD">UPM: Private method is never called</a></td><td>Performance</td></tr> 375 <tr bgcolor="#ffffff"><td><a href="#URF_UNREAD_FIELD">UrF: Unread field</a></td><td>Performance</td></tr> 376 <tr bgcolor="#eeeeee"><td><a href="#UUF_UNUSED_FIELD">UuF: Unused field</a></td><td>Performance</td></tr> 377 <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> 378 <tr bgcolor="#eeeeee"><td><a href="#DMI_CONSTANT_DB_PASSWORD">Dm: Hardcoded constant database password</a></td><td>Security</td></tr> 379 <tr bgcolor="#ffffff"><td><a href="#DMI_EMPTY_DB_PASSWORD">Dm: Empty database password</a></td><td>Security</td></tr> 380 <tr bgcolor="#eeeeee"><td><a href="#HRS_REQUEST_PARAMETER_TO_COOKIE">HRS: HTTP cookie formed from untrusted input</a></td><td>Security</td></tr> 381 <tr bgcolor="#ffffff"><td><a href="#HRS_REQUEST_PARAMETER_TO_HTTP_HEADER">HRS: HTTP Response splitting vulnerability</a></td><td>Security</td></tr> 382 <tr bgcolor="#eeeeee"><td><a href="#PT_ABSOLUTE_PATH_TRAVERSAL">PT: Absolute path traversal in servlet</a></td><td>Security</td></tr> 383 <tr bgcolor="#ffffff"><td><a href="#PT_RELATIVE_PATH_TRAVERSAL">PT: Relative path traversal in servlet</a></td><td>Security</td></tr> 384 <tr bgcolor="#eeeeee"><td><a href="#SQL_NONCONSTANT_STRING_PASSED_TO_EXECUTE">SQL: Nonconstant string passed to execute method on an SQL statement</a></td><td>Security</td></tr> 385 <tr bgcolor="#ffffff"><td><a href="#SQL_PREPARED_STATEMENT_GENERATED_FROM_NONCONSTANT_STRING">SQL: A prepared statement is generated from a nonconstant String</a></td><td>Security</td></tr> 386 <tr bgcolor="#eeeeee"><td><a href="#XSS_REQUEST_PARAMETER_TO_JSP_WRITER">XSS: JSP reflected cross site scripting vulnerability</a></td><td>Security</td></tr> 387 <tr bgcolor="#ffffff"><td><a href="#XSS_REQUEST_PARAMETER_TO_SEND_ERROR">XSS: Servlet reflected cross site scripting vulnerability in error page</a></td><td>Security</td></tr> 388 <tr bgcolor="#eeeeee"><td><a href="#XSS_REQUEST_PARAMETER_TO_SERVLET_WRITER">XSS: Servlet reflected cross site scripting vulnerability</a></td><td>Security</td></tr> 389 <tr bgcolor="#ffffff"><td><a href="#BC_BAD_CAST_TO_ABSTRACT_COLLECTION">BC: Questionable cast to abstract collection </a></td><td>Dodgy code</td></tr> 390 <tr bgcolor="#eeeeee"><td><a href="#BC_BAD_CAST_TO_CONCRETE_COLLECTION">BC: Questionable cast to concrete collection</a></td><td>Dodgy code</td></tr> 391 <tr bgcolor="#ffffff"><td><a href="#BC_UNCONFIRMED_CAST">BC: Unchecked/unconfirmed cast</a></td><td>Dodgy code</td></tr> 392 <tr bgcolor="#eeeeee"><td><a href="#BC_UNCONFIRMED_CAST_OF_RETURN_VALUE">BC: Unchecked/unconfirmed cast of return value from method</a></td><td>Dodgy code</td></tr> 393 <tr bgcolor="#ffffff"><td><a href="#BC_VACUOUS_INSTANCEOF">BC: instanceof will always return true</a></td><td>Dodgy code</td></tr> 394 <tr bgcolor="#eeeeee"><td><a href="#ICAST_QUESTIONABLE_UNSIGNED_RIGHT_SHIFT">BSHIFT: Unsigned right shift cast to short/byte</a></td><td>Dodgy code</td></tr> 395 <tr bgcolor="#ffffff"><td><a href="#CI_CONFUSED_INHERITANCE">CI: Class is final but declares protected field</a></td><td>Dodgy code</td></tr> 396 <tr bgcolor="#eeeeee"><td><a href="#DB_DUPLICATE_BRANCHES">DB: Method uses the same code for two branches</a></td><td>Dodgy code</td></tr> 397 <tr bgcolor="#ffffff"><td><a href="#DB_DUPLICATE_SWITCH_CLAUSES">DB: Method uses the same code for two switch clauses</a></td><td>Dodgy code</td></tr> 398 <tr bgcolor="#eeeeee"><td><a href="#DLS_DEAD_LOCAL_STORE">DLS: Dead store to local variable</a></td><td>Dodgy code</td></tr> 399 <tr bgcolor="#ffffff"><td><a href="#DLS_DEAD_LOCAL_STORE_IN_RETURN">DLS: Useless assignment in return statement</a></td><td>Dodgy code</td></tr> 400 <tr bgcolor="#eeeeee"><td><a href="#DLS_DEAD_LOCAL_STORE_OF_NULL">DLS: Dead store of null to local variable</a></td><td>Dodgy code</td></tr> 401 <tr bgcolor="#ffffff"><td><a href="#DLS_DEAD_LOCAL_STORE_SHADOWS_FIELD">DLS: Dead store to local variable that shadows field</a></td><td>Dodgy code</td></tr> 402 <tr bgcolor="#eeeeee"><td><a href="#DMI_HARDCODED_ABSOLUTE_FILENAME">DMI: Code contains a hard coded reference to an absolute pathname</a></td><td>Dodgy code</td></tr> 403 <tr bgcolor="#ffffff"><td><a href="#DMI_NONSERIALIZABLE_OBJECT_WRITTEN">DMI: Non serializable object written to ObjectOutput</a></td><td>Dodgy code</td></tr> 404 <tr bgcolor="#eeeeee"><td><a href="#DMI_USELESS_SUBSTRING">DMI: Invocation of substring(0), which returns the original value</a></td><td>Dodgy code</td></tr> 405 <tr bgcolor="#ffffff"><td><a href="#DMI_THREAD_PASSED_WHERE_RUNNABLE_EXPECTED">Dm: Thread passed where Runnable expected</a></td><td>Dodgy code</td></tr> 406 <tr bgcolor="#eeeeee"><td><a href="#EQ_DOESNT_OVERRIDE_EQUALS">Eq: Class doesn't override equals in superclass</a></td><td>Dodgy code</td></tr> 407 <tr bgcolor="#ffffff"><td><a href="#EQ_UNUSUAL">Eq: Unusual equals method </a></td><td>Dodgy code</td></tr> 408 <tr bgcolor="#eeeeee"><td><a href="#FE_FLOATING_POINT_EQUALITY">FE: Test for floating point equality</a></td><td>Dodgy code</td></tr> 409 <tr bgcolor="#ffffff"><td><a href="#VA_FORMAT_STRING_BAD_CONVERSION_TO_BOOLEAN">FS: Non-Boolean argument formatted using %b format specifier</a></td><td>Dodgy code</td></tr> 410 <tr bgcolor="#eeeeee"><td><a href="#IA_AMBIGUOUS_INVOCATION_OF_INHERITED_OR_OUTER_METHOD">IA: Potentially ambiguous invocation of either an inherited or outer method</a></td><td>Dodgy code</td></tr> 411 <tr bgcolor="#ffffff"><td><a href="#IC_INIT_CIRCULARITY">IC: Initialization circularity</a></td><td>Dodgy code</td></tr> 412 <tr bgcolor="#eeeeee"><td><a href="#ICAST_IDIV_CAST_TO_DOUBLE">ICAST: Integral division result cast to double or float</a></td><td>Dodgy code</td></tr> 413 <tr bgcolor="#ffffff"><td><a href="#ICAST_INTEGER_MULTIPLY_CAST_TO_LONG">ICAST: Result of integer multiplication cast to long</a></td><td>Dodgy code</td></tr> 414 <tr bgcolor="#eeeeee"><td><a href="#IM_AVERAGE_COMPUTATION_COULD_OVERFLOW">IM: Computation of average could overflow</a></td><td>Dodgy code</td></tr> 415 <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 code</td></tr> 416 <tr bgcolor="#eeeeee"><td><a href="#INT_BAD_REM_BY_1">INT: Integer remainder modulo 1</a></td><td>Dodgy code</td></tr> 417 <tr bgcolor="#ffffff"><td><a href="#INT_VACUOUS_BIT_OPERATION">INT: Vacuous bit mask operation on integer value</a></td><td>Dodgy code</td></tr> 418 <tr bgcolor="#eeeeee"><td><a href="#INT_VACUOUS_COMPARISON">INT: Vacuous comparison of integer value</a></td><td>Dodgy code</td></tr> 419 <tr bgcolor="#ffffff"><td><a href="#MTIA_SUSPECT_SERVLET_INSTANCE_FIELD">MTIA: Class extends Servlet class and uses instance variables</a></td><td>Dodgy code</td></tr> 420 <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 code</td></tr> 421 <tr bgcolor="#ffffff"><td><a href="#NP_DEREFERENCE_OF_READLINE_VALUE">NP: Dereference of the result of readLine() without nullcheck</a></td><td>Dodgy code</td></tr> 422 <tr bgcolor="#eeeeee"><td><a href="#NP_IMMEDIATE_DEREFERENCE_OF_READLINE">NP: Immediate dereference of the result of readLine()</a></td><td>Dodgy code</td></tr> 423 <tr bgcolor="#ffffff"><td><a href="#NP_LOAD_OF_KNOWN_NULL_VALUE">NP: Load of known null value</a></td><td>Dodgy code</td></tr> 424 <tr bgcolor="#eeeeee"><td><a href="#NP_METHOD_PARAMETER_TIGHTENS_ANNOTATION">NP: Method tightens nullness annotation on parameter</a></td><td>Dodgy code</td></tr> 425 <tr bgcolor="#ffffff"><td><a href="#NP_METHOD_RETURN_RELAXING_ANNOTATION">NP: Method relaxes nullness annotation on return value</a></td><td>Dodgy code</td></tr> 426 <tr bgcolor="#eeeeee"><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 code</td></tr> 427 <tr bgcolor="#ffffff"><td><a href="#NP_NULL_ON_SOME_PATH_MIGHT_BE_INFEASIBLE">NP: Possible null pointer dereference on branch that might be infeasible</a></td><td>Dodgy code</td></tr> 428 <tr bgcolor="#eeeeee"><td><a href="#NP_PARAMETER_MUST_BE_NONNULL_BUT_MARKED_AS_NULLABLE">NP: Parameter must be nonnull but is marked as nullable</a></td><td>Dodgy code</td></tr> 429 <tr bgcolor="#ffffff"><td><a href="#NP_UNWRITTEN_PUBLIC_OR_PROTECTED_FIELD">NP: Read of unwritten public or protected field</a></td><td>Dodgy code</td></tr> 430 <tr bgcolor="#eeeeee"><td><a href="#NS_DANGEROUS_NON_SHORT_CIRCUIT">NS: Potentially dangerous use of non-short-circuit logic</a></td><td>Dodgy code</td></tr> 431 <tr bgcolor="#ffffff"><td><a href="#NS_NON_SHORT_CIRCUIT">NS: Questionable use of non-short-circuit logic</a></td><td>Dodgy code</td></tr> 432 <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 code</td></tr> 433 <tr bgcolor="#ffffff"><td><a href="#QF_QUESTIONABLE_FOR_LOOP">QF: Complicated, subtle or wrong increment in for-loop </a></td><td>Dodgy code</td></tr> 434 <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 code</td></tr> 435 <tr bgcolor="#ffffff"><td><a href="#RCN_REDUNDANT_COMPARISON_TWO_NULL_VALUES">RCN: Redundant comparison of two null values</a></td><td>Dodgy code</td></tr> 436 <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 code</td></tr> 437 <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 code</td></tr> 438 <tr bgcolor="#eeeeee"><td><a href="#REC_CATCH_EXCEPTION">REC: Exception is caught when Exception is not thrown</a></td><td>Dodgy code</td></tr> 439 <tr bgcolor="#ffffff"><td><a href="#RI_REDUNDANT_INTERFACES">RI: Class implements same interface as superclass</a></td><td>Dodgy code</td></tr> 440 <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 code</td></tr> 441 <tr bgcolor="#ffffff"><td><a href="#RV_DONT_JUST_NULL_CHECK_READLINE">RV: Method discards result of readLine after checking if it is nonnull</a></td><td>Dodgy code</td></tr> 442 <tr bgcolor="#eeeeee"><td><a href="#RV_REM_OF_HASHCODE">RV: Remainder of hashCode could be negative</a></td><td>Dodgy code</td></tr> 443 <tr bgcolor="#ffffff"><td><a href="#RV_REM_OF_RANDOM_INT">RV: Remainder of 32-bit signed random integer</a></td><td>Dodgy code</td></tr> 444 <tr bgcolor="#eeeeee"><td><a href="#RV_RETURN_VALUE_IGNORED_INFERRED">RV: Method ignores return value, is this OK?</a></td><td>Dodgy code</td></tr> 445 <tr bgcolor="#ffffff"><td><a href="#SA_FIELD_DOUBLE_ASSIGNMENT">SA: Double assignment of field</a></td><td>Dodgy code</td></tr> 446 <tr bgcolor="#eeeeee"><td><a href="#SA_LOCAL_DOUBLE_ASSIGNMENT">SA: Double assignment of local variable </a></td><td>Dodgy code</td></tr> 447 <tr bgcolor="#ffffff"><td><a href="#SA_LOCAL_SELF_ASSIGNMENT">SA: Self assignment of local variable</a></td><td>Dodgy code</td></tr> 448 <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 code</td></tr> 449 <tr bgcolor="#ffffff"><td><a href="#SF_SWITCH_NO_DEFAULT">SF: Switch statement found where default case is missing</a></td><td>Dodgy code</td></tr> 450 <tr bgcolor="#eeeeee"><td><a href="#ST_WRITE_TO_STATIC_FROM_INSTANCE_METHOD">ST: Write to static field from instance method</a></td><td>Dodgy code</td></tr> 451 <tr bgcolor="#ffffff"><td><a href="#SE_PRIVATE_READ_RESOLVE_NOT_INHERITED">Se: Private readResolve method not inherited by subclasses</a></td><td>Dodgy code</td></tr> 452 <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 code</td></tr> 453 <tr bgcolor="#ffffff"><td><a href="#TQ_EXPLICIT_UNKNOWN_SOURCE_VALUE_REACHES_ALWAYS_SINK">TQ: Value required to have type qualifier, but marked as unknown</a></td><td>Dodgy code</td></tr> 454 <tr bgcolor="#eeeeee"><td><a href="#TQ_EXPLICIT_UNKNOWN_SOURCE_VALUE_REACHES_NEVER_SINK">TQ: Value required to not have type qualifier, but marked as unknown</a></td><td>Dodgy code</td></tr> 455 <tr bgcolor="#ffffff"><td><a href="#UCF_USELESS_CONTROL_FLOW">UCF: Useless control flow</a></td><td>Dodgy code</td></tr> 456 <tr bgcolor="#eeeeee"><td><a href="#UCF_USELESS_CONTROL_FLOW_NEXT_LINE">UCF: Useless control flow to next line</a></td><td>Dodgy code</td></tr> 457 <tr bgcolor="#ffffff"><td><a href="#URF_UNREAD_PUBLIC_OR_PROTECTED_FIELD">UrF: Unread public/protected field</a></td><td>Dodgy code</td></tr> 458 <tr bgcolor="#eeeeee"><td><a href="#UUF_UNUSED_PUBLIC_OR_PROTECTED_FIELD">UuF: Unused public or protected field</a></td><td>Dodgy code</td></tr> 459 <tr bgcolor="#ffffff"><td><a href="#UWF_FIELD_NOT_INITIALIZED_IN_CONSTRUCTOR">UwF: Field not initialized in constructor but dereferenced without null check</a></td><td>Dodgy code</td></tr> 460 <tr bgcolor="#eeeeee"><td><a href="#UWF_UNWRITTEN_PUBLIC_OR_PROTECTED_FIELD">UwF: Unwritten public or protected field</a></td><td>Dodgy code</td></tr> 461 <tr bgcolor="#ffffff"><td><a href="#XFB_XML_FACTORY_BYPASS">XFB: Method directly allocates a specific implementation of xml interfaces</a></td><td>Dodgy code</td></tr> 462 </table> 463 <h2>Descriptions</h2> 464 <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> 465 466 467 <p> 468 The <code>equals(Object o)</code> method shouldn't make any assumptions 469 about the type of <code>o</code>. It should simply return 470 false if <code>o</code> is not the same type as <code>this</code>. 471 </p> 472 473 474 <h3><a name="BIT_SIGNED_CHECK">BIT: Check for sign of bitwise operation (BIT_SIGNED_CHECK)</a></h3> 475 476 477 <p> This method compares an expression such as</p> 478 <pre>((event.detail & SWT.SELECTED) > 0)</pre>. 479 <p>Using bit arithmetic and then comparing with the greater than operator can 480 lead to unexpected results (of course depending on the value of 481 SWT.SELECTED). If SWT.SELECTED is a negative number, this is a candidate 482 for a bug. Even when SWT.SELECTED is not negative, it seems good practice 483 to use '!= 0' instead of '> 0'. 484 </p> 485 <p> 486 <em>Boris Bokowski</em> 487 </p> 488 489 490 <h3><a name="CN_IDIOM">CN: Class implements Cloneable but does not define or use clone method (CN_IDIOM)</a></h3> 491 492 493 <p> 494 Class implements Cloneable but does not define or 495 use the clone method.</p> 496 497 498 <h3><a name="CN_IDIOM_NO_SUPER_CALL">CN: clone method does not call super.clone() (CN_IDIOM_NO_SUPER_CALL)</a></h3> 499 500 501 <p> This non-final class defines a clone() method that does not call super.clone(). 502 If this class ("<i>A</i>") is extended by a subclass ("<i>B</i>"), 503 and the subclass <i>B</i> calls super.clone(), then it is likely that 504 <i>B</i>'s clone() method will return an object of type <i>A</i>, 505 which violates the standard contract for clone().</p> 506 507 <p> If all clone() methods call super.clone(), then they are guaranteed 508 to use Object.clone(), which always returns an object of the correct type.</p> 509 510 511 <h3><a name="CN_IMPLEMENTS_CLONE_BUT_NOT_CLONEABLE">CN: Class defines clone() but doesn't implement Cloneable (CN_IMPLEMENTS_CLONE_BUT_NOT_CLONEABLE)</a></h3> 512 513 514 <p> This class defines a clone() method but the class doesn't implement Cloneable. 515 There are some situations in which this is OK (e.g., you want to control how subclasses 516 can clone themselves), but just make sure that this is what you intended. 517 </p> 518 519 520 <h3><a name="CO_ABSTRACT_SELF">Co: Abstract class defines covariant compareTo() method (CO_ABSTRACT_SELF)</a></h3> 521 522 523 <p> This class defines a covariant version of <code>compareTo()</code>. 524 To correctly override the <code>compareTo()</code> method in the 525 <code>Comparable</code> interface, the parameter of <code>compareTo()</code> 526 must have type <code>java.lang.Object</code>.</p> 527 528 529 <h3><a name="CO_SELF_NO_OBJECT">Co: Covariant compareTo() method defined (CO_SELF_NO_OBJECT)</a></h3> 530 531 532 <p> This class defines a covariant version of <code>compareTo()</code>. 533 To correctly override the <code>compareTo()</code> method in the 534 <code>Comparable</code> interface, the parameter of <code>compareTo()</code> 535 must have type <code>java.lang.Object</code>.</p> 536 537 538 <h3><a name="DE_MIGHT_DROP">DE: Method might drop exception (DE_MIGHT_DROP)</a></h3> 539 540 541 <p> This method might drop an exception. In general, exceptions 542 should be handled or reported in some way, or they should be thrown 543 out of the method.</p> 544 545 546 <h3><a name="DE_MIGHT_IGNORE">DE: Method might ignore exception (DE_MIGHT_IGNORE)</a></h3> 547 548 549 <p> This method might ignore an exception. In general, exceptions 550 should be handled or reported in some way, or they should be thrown 551 out of the method.</p> 552 553 554 <h3><a name="DMI_ENTRY_SETS_MAY_REUSE_ENTRY_OBJECTS">DMI: Adding elements of an entry set may fail due to reuse of Entry objects (DMI_ENTRY_SETS_MAY_REUSE_ENTRY_OBJECTS)</a></h3> 555 556 557 <p> The entrySet() method is allowed to return a view of the 558 underlying Map in which a single Entry object is reused and returned 559 during the iteration. As of Java 1.6, both IdentityHashMap 560 and EnumMap did so. When iterating through such a Map, 561 the Entry value is only valid until you advance to the next iteration. 562 If, for example, you try to pass such an entrySet to an addAll method, 563 things will go badly wrong. 564 </p> 565 566 567 <h3><a name="DMI_RANDOM_USED_ONLY_ONCE">DMI: Random object created and used only once (DMI_RANDOM_USED_ONLY_ONCE)</a></h3> 568 569 570 <p> This code creates a java.util.Random object, uses it to generate one random number, and then discards 571 the Random object. This produces mediocre quality random numbers and is inefficient. 572 If possible, rewrite the code so that the Random object is created once and saved, and each time a new random number 573 is required invoke a method on the existing Random object to obtain it. 574 </p> 575 576 <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 577 number; the values are too easily guessable. You should strongly consider using a java.security.SecureRandom instead 578 (and avoid allocating a new SecureRandom for each random number needed). 579 </p> 580 581 582 <h3><a name="DMI_USING_REMOVEALL_TO_CLEAR_COLLECTION">DMI: Don't use removeAll to clear a collection (DMI_USING_REMOVEALL_TO_CLEAR_COLLECTION)</a></h3> 583 584 585 <p> If you want to remove all elements from a collection <code>c</code>, use <code>c.clear</code>, 586 not <code>c.removeAll(c)</code>. Calling <code>c.removeAll(c)</code> to clear a collection 587 is less clear, susceptible to errors from typos, less efficient and 588 for some collections, might throw a <code>ConcurrentModificationException</code>. 589 </p> 590 591 592 <h3><a name="DM_EXIT">Dm: Method invokes System.exit(...) (DM_EXIT)</a></h3> 593 594 595 <p> Invoking System.exit shuts down the entire Java virtual machine. This 596 should only been done when it is appropriate. Such calls make it 597 hard or impossible for your code to be invoked by other code. 598 Consider throwing a RuntimeException instead.</p> 599 600 601 <h3><a name="DM_RUN_FINALIZERS_ON_EXIT">Dm: Method invokes dangerous method runFinalizersOnExit (DM_RUN_FINALIZERS_ON_EXIT)</a></h3> 602 603 604 <p> <em>Never call System.runFinalizersOnExit 605 or Runtime.runFinalizersOnExit for any reason: they are among the most 606 dangerous methods in the Java libraries.</em> -- Joshua Bloch</p> 607 608 609 <h3><a name="ES_COMPARING_PARAMETER_STRING_WITH_EQ">ES: Comparison of String parameter using == or != (ES_COMPARING_PARAMETER_STRING_WITH_EQ)</a></h3> 610 611 612 <p>This code compares a <code>java.lang.String</code> parameter for reference 613 equality using the == or != operators. Requiring callers to 614 pass only String constants or interned strings to a method is unnecessarily 615 fragile, and rarely leads to measurable performance gains. Consider 616 using the <code>equals(Object)</code> method instead.</p> 617 618 619 <h3><a name="ES_COMPARING_STRINGS_WITH_EQ">ES: Comparison of String objects using == or != (ES_COMPARING_STRINGS_WITH_EQ)</a></h3> 620 621 622 <p>This code compares <code>java.lang.String</code> objects for reference 623 equality using the == or != operators. 624 Unless both strings are either constants in a source file, or have been 625 interned using the <code>String.intern()</code> method, the same string 626 value may be represented by two different String objects. Consider 627 using the <code>equals(Object)</code> method instead.</p> 628 629 630 <h3><a name="EQ_ABSTRACT_SELF">Eq: Abstract class defines covariant equals() method (EQ_ABSTRACT_SELF)</a></h3> 631 632 633 <p> This class defines a covariant version of <code>equals()</code>. 634 To correctly override the <code>equals()</code> method in 635 <code>java.lang.Object</code>, the parameter of <code>equals()</code> 636 must have type <code>java.lang.Object</code>.</p> 637 638 639 <h3><a name="EQ_CHECK_FOR_OPERAND_NOT_COMPATIBLE_WITH_THIS">Eq: Equals checks for incompatible operand (EQ_CHECK_FOR_OPERAND_NOT_COMPATIBLE_WITH_THIS)</a></h3> 640 641 642 <p> This equals method is checking to see if the argument is some incompatible type 643 (i.e., a class that is neither a supertype nor subtype of the class that defines 644 the equals method). For example, the Foo class might have an equals method 645 that looks like: 646 </p> 647 <pre> 648 public boolean equals(Object o) { 649 if (o instanceof Foo) 650 return name.equals(((Foo)o).name); 651 else if (o instanceof String) 652 return name.equals(o); 653 else return false; 654 </pre> 655 656 <p>This is considered bad practice, as it makes it very hard to implement an equals method that 657 is symmetric and transitive. Without those properties, very unexpected behavoirs are possible. 658 </p> 659 660 661 <h3><a name="EQ_COMPARETO_USE_OBJECT_EQUALS">Eq: Class defines compareTo(...) and uses Object.equals() (EQ_COMPARETO_USE_OBJECT_EQUALS)</a></h3> 662 663 664 <p> This class defines a <code>compareTo(...)</code> method but inherits its 665 <code>equals()</code> method from <code>java.lang.Object</code>. 666 Generally, the value of compareTo should return zero if and only if 667 equals returns true. If this is violated, weird and unpredictable 668 failures will occur in classes such as PriorityQueue. 669 In Java 5 the PriorityQueue.remove method uses the compareTo method, 670 while in Java 6 it uses the equals method. 671 672 <p>From the JavaDoc for the compareTo method in the Comparable interface: 673 <blockquote> 674 It is strongly recommended, but not strictly required that <code>(x.compareTo(y)==0) == (x.equals(y))</code>. 675 Generally speaking, any class that implements the Comparable interface and violates this condition 676 should clearly indicate this fact. The recommended language 677 is "Note: this class has a natural ordering that is inconsistent with equals." 678 </blockquote> 679 680 681 <h3><a name="EQ_GETCLASS_AND_CLASS_CONSTANT">Eq: equals method fails for subtypes (EQ_GETCLASS_AND_CLASS_CONSTANT)</a></h3> 682 683 684 <p> This class has an equals method that will be broken if it is inherited by subclasses. 685 It compares a class literal with the class of the argument (e.g., in class <code>Foo</code> 686 it might check if <code>Foo.class == o.getClass()</code>). 687 It is better to check if <code>this.getClass() == o.getClass()</code>. 688 </p> 689 690 691 <h3><a name="EQ_SELF_NO_OBJECT">Eq: Covariant equals() method defined (EQ_SELF_NO_OBJECT)</a></h3> 692 693 694 <p> This class defines a covariant version of <code>equals()</code>. 695 To correctly override the <code>equals()</code> method in 696 <code>java.lang.Object</code>, the parameter of <code>equals()</code> 697 must have type <code>java.lang.Object</code>.</p> 698 699 700 <h3><a name="FI_EMPTY">FI: Empty finalizer should be deleted (FI_EMPTY)</a></h3> 701 702 703 <p> Empty <code>finalize()</code> methods are useless, so they should 704 be deleted.</p> 705 706 707 <h3><a name="FI_EXPLICIT_INVOCATION">FI: Explicit invocation of finalizer (FI_EXPLICIT_INVOCATION)</a></h3> 708 709 710 <p> This method contains an explicit invocation of the <code>finalize()</code> 711 method on an object. Because finalizer methods are supposed to be 712 executed once, and only by the VM, this is a bad idea.</p> 713 <p>If a connected set of objects beings finalizable, then the VM will invoke the 714 finalize method on all the finalizable object, possibly at the same time in different threads. 715 Thus, it is a particularly bad idea, in the finalize method for a class X, invoke finalize 716 on objects referenced by X, because they may already be getting finalized in a separate thread. 717 718 719 <h3><a name="FI_FINALIZER_NULLS_FIELDS">FI: Finalizer nulls fields (FI_FINALIZER_NULLS_FIELDS)</a></h3> 720 721 722 <p> This finalizer nulls out fields. This is usually an error, as it does not aid garbage collection, 723 and the object is going to be garbage collected anyway. 724 725 726 <h3><a name="FI_FINALIZER_ONLY_NULLS_FIELDS">FI: Finalizer only nulls fields (FI_FINALIZER_ONLY_NULLS_FIELDS)</a></h3> 727 728 729 <p> This finalizer does nothing except null out fields. This is completely pointless, and requires that 730 the object be garbage collected, finalized, and then garbage collected again. You should just remove the finalize 731 method. 732 733 734 <h3><a name="FI_MISSING_SUPER_CALL">FI: Finalizer does not call superclass finalizer (FI_MISSING_SUPER_CALL)</a></h3> 735 736 737 <p> This <code>finalize()</code> method does not make a call to its 738 superclass's <code>finalize()</code> method. So, any finalizer 739 actions defined for the superclass will not be performed. 740 Add a call to <code>super.finalize()</code>.</p> 741 742 743 <h3><a name="FI_NULLIFY_SUPER">FI: Finalizer nullifies superclass finalizer (FI_NULLIFY_SUPER)</a></h3> 744 745 746 <p> This empty <code>finalize()</code> method explicitly negates the 747 effect of any finalizer defined by its superclass. Any finalizer 748 actions defined for the superclass will not be performed. 749 Unless this is intended, delete this method.</p> 750 751 752 <h3><a name="FI_USELESS">FI: Finalizer does nothing but call superclass finalizer (FI_USELESS)</a></h3> 753 754 755 <p> The only thing this <code>finalize()</code> method does is call 756 the superclass's <code>finalize()</code> method, making it 757 redundant. Delete it.</p> 758 759 760 <h3><a name="VA_FORMAT_STRING_USES_NEWLINE">FS: Format string should use %n rather than \n (VA_FORMAT_STRING_USES_NEWLINE)</a></h3> 761 762 763 <p> 764 This format string include a newline character (\n). In format strings, it is generally 765 preferable better to use %n, which will produce the platform-specific line separator. 766 </p> 767 768 769 <h3><a name="GC_UNCHECKED_TYPE_IN_GENERIC_CALL">GC: Unchecked type in generic call (GC_UNCHECKED_TYPE_IN_GENERIC_CALL)</a></h3> 770 771 772 <p> This call to a generic collection method passes an argument 773 while compile type Object where a specific type from 774 the generic type parameters is expected. 775 Thus, neither the standard Java type system nor static analysis 776 can provide useful information on whether the 777 object being passed as a parameter is of an appropriate type. 778 </p> 779 780 781 <h3><a name="HE_EQUALS_NO_HASHCODE">HE: Class defines equals() but not hashCode() (HE_EQUALS_NO_HASHCODE)</a></h3> 782 783 784 <p> This class overrides <code>equals(Object)</code>, but does not 785 override <code>hashCode()</code>. Therefore, the class may violate the 786 invariant that equal objects must have equal hashcodes.</p> 787 788 789 <h3><a name="HE_EQUALS_USE_HASHCODE">HE: Class defines equals() and uses Object.hashCode() (HE_EQUALS_USE_HASHCODE)</a></h3> 790 791 792 <p> This class overrides <code>equals(Object)</code>, but does not 793 override <code>hashCode()</code>, and inherits the implementation of 794 <code>hashCode()</code> from <code>java.lang.Object</code> (which returns 795 the identity hash code, an arbitrary value assigned to the object 796 by the VM). Therefore, the class is very likely to violate the 797 invariant that equal objects must have equal hashcodes.</p> 798 799 <p>If you don't think instances of this class will ever be inserted into a HashMap/HashTable, 800 the recommended <code>hashCode</code> implementation to use is:</p> 801 <pre>public int hashCode() { 802 assert false : "hashCode not designed"; 803 return 42; // any arbitrary constant will do 804 }</pre> 805 806 807 <h3><a name="HE_HASHCODE_NO_EQUALS">HE: Class defines hashCode() but not equals() (HE_HASHCODE_NO_EQUALS)</a></h3> 808 809 810 <p> This class defines a <code>hashCode()</code> method but not an 811 <code>equals()</code> method. Therefore, the class may 812 violate the invariant that equal objects must have equal hashcodes.</p> 813 814 815 <h3><a name="HE_HASHCODE_USE_OBJECT_EQUALS">HE: Class defines hashCode() and uses Object.equals() (HE_HASHCODE_USE_OBJECT_EQUALS)</a></h3> 816 817 818 <p> This class defines a <code>hashCode()</code> method but inherits its 819 <code>equals()</code> method from <code>java.lang.Object</code> 820 (which defines equality by comparing object references). Although 821 this will probably satisfy the contract that equal objects must have 822 equal hashcodes, it is probably not what was intended by overriding 823 the <code>hashCode()</code> method. (Overriding <code>hashCode()</code> 824 implies that the object's identity is based on criteria more complicated 825 than simple reference equality.)</p> 826 <p>If you don't think instances of this class will ever be inserted into a HashMap/HashTable, 827 the recommended <code>hashCode</code> implementation to use is:</p> 828 <pre>public int hashCode() { 829 assert false : "hashCode not designed"; 830 return 42; // any arbitrary constant will do 831 }</pre> 832 833 834 <h3><a name="HE_INHERITS_EQUALS_USE_HASHCODE">HE: Class inherits equals() and uses Object.hashCode() (HE_INHERITS_EQUALS_USE_HASHCODE)</a></h3> 835 836 837 <p> This class inherits <code>equals(Object)</code> from an abstract 838 superclass, and <code>hashCode()</code> from 839 <code>java.lang.Object</code> (which returns 840 the identity hash code, an arbitrary value assigned to the object 841 by the VM). Therefore, the class is very likely to violate the 842 invariant that equal objects must have equal hashcodes.</p> 843 844 <p>If you don't want to define a hashCode method, and/or don't 845 believe the object will ever be put into a HashMap/Hashtable, 846 define the <code>hashCode()</code> method 847 to throw <code>UnsupportedOperationException</code>.</p> 848 849 850 <h3><a name="IC_SUPERCLASS_USES_SUBCLASS_DURING_INITIALIZATION">IC: Superclass uses subclass during initialization (IC_SUPERCLASS_USES_SUBCLASS_DURING_INITIALIZATION)</a></h3> 851 852 853 <p> During the initialization of a class, the class makes an active use of a subclass. 854 That subclass will not yet be initialized at the time of this use. 855 For example, in the following code, <code>foo</code> will be null.</p> 856 857 <pre> 858 public class CircularClassInitialization { 859 static class InnerClassSingleton extends CircularClassInitialization { 860 static InnerClassSingleton singleton = new InnerClassSingleton(); 861 } 862 863 static CircularClassInitialization foo = InnerClassSingleton.singleton; 864 } 865 </pre> 866 867 868 869 <h3><a name="IMSE_DONT_CATCH_IMSE">IMSE: Dubious catching of IllegalMonitorStateException (IMSE_DONT_CATCH_IMSE)</a></h3> 870 871 872 <p>IllegalMonitorStateException is generally only 873 thrown in case of a design flaw in your code (calling wait or 874 notify on an object you do not hold a lock on).</p> 875 876 877 <h3><a name="ISC_INSTANTIATE_STATIC_CLASS">ISC: Needless instantiation of class that only supplies static methods (ISC_INSTANTIATE_STATIC_CLASS)</a></h3> 878 879 880 <p> This class allocates an object that is based on a class that only supplies static methods. This object 881 does not need to be created, just access the static methods directly using the class name as a qualifier.</p> 882 883 884 <h3><a name="IT_NO_SUCH_ELEMENT">It: Iterator next() method can't throw NoSuchElementException (IT_NO_SUCH_ELEMENT)</a></h3> 885 886 887 <p> This class implements the <code>java.util.Iterator</code> interface. 888 However, its <code>next()</code> method is not capable of throwing 889 <code>java.util.NoSuchElementException</code>. The <code>next()</code> 890 method should be changed so it throws <code>NoSuchElementException</code> 891 if is called when there are no more elements to return.</p> 892 893 894 <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> 895 896 897 <p> 898 This code seems to be storing a non-serializable object into an HttpSession. 899 If this session is passivated or migrated, an error will result. 900 </p> 901 902 903 <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> 904 905 906 <p> The class is annotated with net.jcip.annotations.Immutable or javax.annotation.concurrent.Immutable, 907 and the rules for those annotations require that all fields are final. 908 .</p> 909 910 911 <h3><a name="NP_BOOLEAN_RETURN_NULL">NP: Method with Boolean return type returns explicit null (NP_BOOLEAN_RETURN_NULL)</a></h3> 912 913 914 <p> 915 A method that returns either Boolean.TRUE, Boolean.FALSE or null is an accident waiting to happen. 916 This method can be invoked as though it returned a value of type boolean, and 917 the compiler will insert automatic unboxing of the Boolean value. If a null value is returned, 918 this will result in a NullPointerException. 919 </p> 920 921 922 <h3><a name="NP_CLONE_COULD_RETURN_NULL">NP: Clone method may return null (NP_CLONE_COULD_RETURN_NULL)</a></h3> 923 924 925 <p> 926 This clone method seems to return null in some circumstances, but clone is never 927 allowed to return a null value. If you are convinced this path is unreachable, throw an AssertionError 928 instead. 929 </p> 930 931 932 <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> 933 934 935 <p> 936 This implementation of equals(Object) violates the contract defined 937 by java.lang.Object.equals() because it does not check for null 938 being passed as the argument. All equals() methods should return 939 false if passed a null value. 940 </p> 941 942 943 <h3><a name="NP_TOSTRING_COULD_RETURN_NULL">NP: toString method may return null (NP_TOSTRING_COULD_RETURN_NULL)</a></h3> 944 945 946 <p> 947 This toString method seems to return null in some circumstances. A liberal reading of the 948 spec could be interpreted as allowing this, but it is probably a bad idea and could cause 949 other code to break. Return the empty string or some other appropriate string rather than null. 950 </p> 951 952 953 <h3><a name="NM_CLASS_NAMING_CONVENTION">Nm: Class names should start with an upper case letter (NM_CLASS_NAMING_CONVENTION)</a></h3> 954 955 956 <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). 957 </p> 958 959 960 <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> 961 962 963 <p> This class is not derived from another exception, but ends with 'Exception'. This will 964 be confusing to users of this class.</p> 965 966 967 <h3><a name="NM_CONFUSING">Nm: Confusing method names (NM_CONFUSING)</a></h3> 968 969 970 <p> The referenced methods have names that differ only by capitalization.</p> 971 972 973 <h3><a name="NM_FIELD_NAMING_CONVENTION">Nm: Field names should start with a lower case letter (NM_FIELD_NAMING_CONVENTION)</a></h3> 974 975 976 <p> 977 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. 978 </p> 979 980 981 <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> 982 983 984 <p>The identifier is a word that is reserved as a keyword in later versions of Java, and your code will need to be changed 985 in order to compile it in later versions of Java.</p> 986 987 988 989 <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> 990 991 992 <p>This identifier is used as a keyword in later versions of Java. This code, and 993 any code that references this API, 994 will need to be changed in order to compile it in later versions of Java.</p> 995 996 997 998 <h3><a name="NM_METHOD_NAMING_CONVENTION">Nm: Method names should start with a lower case letter (NM_METHOD_NAMING_CONVENTION)</a></h3> 999 1000 1001 <p> 1002 Methods should be verbs, in mixed case with the first letter lowercase, with the first letter of each internal word capitalized. 1003 </p> 1004 1005 1006 <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> 1007 1008 1009 <p> This class/interface has a simple name that is identical to that of an implemented/extended interface, except 1010 that the interface is in a different package (e.g., <code>alpha.Foo</code> extends <code>beta.Foo</code>). 1011 This can be exceptionally confusing, create lots of situations in which you have to look at import statements 1012 to resolve references and creates many 1013 opportunities to accidently define methods that do not override methods in their superclasses. 1014 </p> 1015 1016 1017 <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> 1018 1019 1020 <p> This class has a simple name that is identical to that of its superclass, except 1021 that its superclass is in a different package (e.g., <code>alpha.Foo</code> extends <code>beta.Foo</code>). 1022 This can be exceptionally confusing, create lots of situations in which you have to look at import statements 1023 to resolve references and creates many 1024 opportunities to accidently define methods that do not override methods in their superclasses. 1025 </p> 1026 1027 1028 <h3><a name="NM_VERY_CONFUSING_INTENTIONAL">Nm: Very confusing method names (but perhaps intentional) (NM_VERY_CONFUSING_INTENTIONAL)</a></h3> 1029 1030 1031 <p> The referenced methods have names that differ only by capitalization. 1032 This is very confusing because if the capitalization were 1033 identical then one of the methods would override the other. From the existence of other methods, it 1034 seems that the existence of both of these methods is intentional, but is sure is confusing. 1035 You should try hard to eliminate one of them, unless you are forced to have both due to frozen APIs. 1036 </p> 1037 1038 1039 <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> 1040 1041 1042 <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 1043 the type of the corresponding parameter in the superclass. For example, if you have:</p> 1044 1045 <blockquote> 1046 <pre> 1047 import alpha.Foo; 1048 public class A { 1049 public int f(Foo x) { return 17; } 1050 } 1051 ---- 1052 import beta.Foo; 1053 public class B extends A { 1054 public int f(Foo x) { return 42; } 1055 public int f(alpha.Foo x) { return 27; } 1056 } 1057 </pre> 1058 </blockquote> 1059 1060 <p>The <code>f(Foo)</code> method defined in class <code>B</code> doesn't 1061 override the 1062 <code>f(Foo)</code> method defined in class <code>A</code>, because the argument 1063 types are <code>Foo</code>'s from different packages. 1064 </p> 1065 1066 <p>In this case, the subclass does define a method with a signature identical to the method in the superclass, 1067 so this is presumably understood. However, such methods are exceptionally confusing. You should strongly consider 1068 removing or deprecating the method with the similar but not identical signature. 1069 </p> 1070 1071 1072 <h3><a name="ODR_OPEN_DATABASE_RESOURCE">ODR: Method may fail to close database resource (ODR_OPEN_DATABASE_RESOURCE)</a></h3> 1073 1074 1075 <p> The method creates a database resource (such as a database connection 1076 or row set), does not assign it to any 1077 fields, pass it to other methods, or return it, and does not appear to close 1078 the object on all paths out of the method. Failure to 1079 close database resources on all paths out of a method may 1080 result in poor performance, and could cause the application to 1081 have problems communicating with the database. 1082 </p> 1083 1084 1085 <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> 1086 1087 1088 <p> The method creates a database resource (such as a database connection 1089 or row set), does not assign it to any 1090 fields, pass it to other methods, or return it, and does not appear to close 1091 the object on all exception paths out of the method. Failure to 1092 close database resources on all paths out of a method may 1093 result in poor performance, and could cause the application to 1094 have problems communicating with the database.</p> 1095 1096 1097 <h3><a name="OS_OPEN_STREAM">OS: Method may fail to close stream (OS_OPEN_STREAM)</a></h3> 1098 1099 1100 <p> The method creates an IO stream object, does not assign it to any 1101 fields, pass it to other methods that might close it, 1102 or return it, and does not appear to close 1103 the stream on all paths out of the method. This may result in 1104 a file descriptor leak. It is generally a good 1105 idea to use a <code>finally</code> block to ensure that streams are 1106 closed.</p> 1107 1108 1109 <h3><a name="OS_OPEN_STREAM_EXCEPTION_PATH">OS: Method may fail to close stream on exception (OS_OPEN_STREAM_EXCEPTION_PATH)</a></h3> 1110 1111 1112 <p> The method creates an IO stream object, does not assign it to any 1113 fields, pass it to other methods, or return it, and does not appear to close 1114 it on all possible exception paths out of the method. 1115 This may result in a file descriptor leak. It is generally a good 1116 idea to use a <code>finally</code> block to ensure that streams are 1117 closed.</p> 1118 1119 1120 <h3><a name="PZ_DONT_REUSE_ENTRY_OBJECTS_IN_ITERATORS">PZ: Don't reuse entry objects in iterators (PZ_DONT_REUSE_ENTRY_OBJECTS_IN_ITERATORS)</a></h3> 1121 1122 1123 <p> The entrySet() method is allowed to return a view of the 1124 underlying Map in which an Iterator and Map.Entry. This clever 1125 idea was used in several Map implementations, but introduces the possibility 1126 of nasty coding mistakes. If a map <code>m</code> returns 1127 such an iterator for an entrySet, then 1128 <code>c.addAll(m.entrySet())</code> will go badly wrong. All of 1129 the Map implementations in OpenJDK 1.7 have been rewritten to avoid this, 1130 you should to. 1131 </p> 1132 1133 1134 <h3><a name="RC_REF_COMPARISON_BAD_PRACTICE">RC: Suspicious reference comparison to constant (RC_REF_COMPARISON_BAD_PRACTICE)</a></h3> 1135 1136 1137 <p> This method compares a reference value to a constant using the == or != operator, 1138 where the correct way to compare instances of this type is generally 1139 with the equals() method. 1140 It is possible to create distinct instances that are equal but do not compare as == since 1141 they are different objects. 1142 Examples of classes which should generally 1143 not be compared by reference are java.lang.Integer, java.lang.Float, etc.</p> 1144 1145 1146 <h3><a name="RC_REF_COMPARISON_BAD_PRACTICE_BOOLEAN">RC: Suspicious reference comparison of Boolean values (RC_REF_COMPARISON_BAD_PRACTICE_BOOLEAN)</a></h3> 1147 1148 1149 <p> This method compares two Boolean values using the == or != operator. 1150 Normally, there are only two Boolean values (Boolean.TRUE and Boolean.FALSE), 1151 but it is possible to create other Boolean objects using the <code>new Boolean(b)</code> 1152 constructor. It is best to avoid such objects, but if they do exist, 1153 then checking Boolean objects for equality using == or != will give results 1154 than are different than you would get using <code>.equals(...)</code> 1155 </p> 1156 1157 1158 <h3><a name="RR_NOT_CHECKED">RR: Method ignores results of InputStream.read() (RR_NOT_CHECKED)</a></h3> 1159 1160 1161 <p> This method ignores the return value of one of the variants of 1162 <code>java.io.InputStream.read()</code> which can return multiple bytes. 1163 If the return value is not checked, the caller will not be able to correctly 1164 handle the case where fewer bytes were read than the caller requested. 1165 This is a particularly insidious kind of bug, because in many programs, 1166 reads from input streams usually do read the full amount of data requested, 1167 causing the program to fail only sporadically.</p> 1168 1169 1170 <h3><a name="SR_NOT_CHECKED">RR: Method ignores results of InputStream.skip() (SR_NOT_CHECKED)</a></h3> 1171 1172 1173 <p> This method ignores the return value of 1174 <code>java.io.InputStream.skip()</code> which can skip multiple bytes. 1175 If the return value is not checked, the caller will not be able to correctly 1176 handle the case where fewer bytes were skipped than the caller requested. 1177 This is a particularly insidious kind of bug, because in many programs, 1178 skips from input streams usually do skip the full amount of data requested, 1179 causing the program to fail only sporadically. With Buffered streams, however, 1180 skip() will only skip data in the buffer, and will routinely fail to skip the 1181 requested number of bytes.</p> 1182 1183 1184 <h3><a name="RV_NEGATING_RESULT_OF_COMPARETO">RV: Negating the result of compareTo()/compare() (RV_NEGATING_RESULT_OF_COMPARETO)</a></h3> 1185 1186 1187 <p> This code negatives the return value of a compareTo or compare method. 1188 This is a questionable or bad programming practice, since if the return 1189 value is Integer.MIN_VALUE, negating the return value won't 1190 negate the sign of the result. You can achieve the same intended result 1191 by reversing the order of the operands rather than by negating the results. 1192 </p> 1193 1194 1195 <h3><a name="RV_RETURN_VALUE_IGNORED_BAD_PRACTICE">RV: Method ignores exceptional return value (RV_RETURN_VALUE_IGNORED_BAD_PRACTICE)</a></h3> 1196 1197 1198 <p> This method returns a value that is not checked. The return value should be checked 1199 since it can indicate an unusual or unexpected function execution. For 1200 example, the <code>File.delete()</code> method returns false 1201 if the file could not be successfully deleted (rather than 1202 throwing an Exception). 1203 If you don't check the result, you won't notice if the method invocation 1204 signals unexpected behavior by returning an atypical return value. 1205 </p> 1206 1207 1208 <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> 1209 1210 1211 <p> The class's static initializer creates an instance of the class 1212 before all of the static final fields are assigned.</p> 1213 1214 1215 <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> 1216 1217 1218 <p>(<a href="http://web.archive.org/web/20090526170426/http://java.sun.com/developer/JDCTechTips/2003/tt1208.html">From JDC Tech Tip</a>): The Swing methods 1219 show(), setVisible(), and pack() will create the associated peer for the frame. 1220 With the creation of the peer, the system creates the event dispatch thread. 1221 This makes things problematic because the event dispatch thread could be notifying 1222 listeners while pack and validate are still processing. This situation could result in 1223 two threads going through the Swing component-based GUI -- it's a serious flaw that 1224 could result in deadlocks or other related threading issues. A pack call causes 1225 components to be realized. As they are being realized (that is, not necessarily 1226 visible), they could trigger listener notification on the event dispatch thread.</p> 1227 1228 1229 1230 <h3><a name="SE_BAD_FIELD">Se: Non-transient non-serializable instance field in serializable class (SE_BAD_FIELD)</a></h3> 1231 1232 1233 <p> This Serializable class defines a non-primitive instance field which is neither transient, 1234 Serializable, or <code>java.lang.Object</code>, and does not appear to implement 1235 the <code>Externalizable</code> interface or the 1236 <code>readObject()</code> and <code>writeObject()</code> methods. 1237 Objects of this class will not be deserialized correctly if a non-Serializable 1238 object is stored in this field.</p> 1239 1240 1241 <h3><a name="SE_BAD_FIELD_INNER_CLASS">Se: Non-serializable class has a serializable inner class (SE_BAD_FIELD_INNER_CLASS)</a></h3> 1242 1243 1244 <p> This Serializable class is an inner class of a non-serializable class. 1245 Thus, attempts to serialize it will also attempt to associate instance of the outer 1246 class with which it is associated, leading to a runtime error. 1247 </p> 1248 <p>If possible, making the inner class a static inner class should solve the 1249 problem. Making the outer class serializable might also work, but that would 1250 mean serializing an instance of the inner class would always also serialize the instance 1251 of the outer class, which it often not what you really want. 1252 1253 1254 <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> 1255 1256 1257 <p> A non-serializable value is stored into a non-transient field 1258 of a serializable class.</p> 1259 1260 1261 <h3><a name="SE_COMPARATOR_SHOULD_BE_SERIALIZABLE">Se: Comparator doesn't implement Serializable (SE_COMPARATOR_SHOULD_BE_SERIALIZABLE)</a></h3> 1262 1263 1264 <p> This class implements the <code>Comparator</code> interface. You 1265 should consider whether or not it should also implement the <code>Serializable</code> 1266 interface. If a comparator is used to construct an ordered collection 1267 such as a <code>TreeMap</code>, then the <code>TreeMap</code> 1268 will be serializable only if the comparator is also serializable. 1269 As most comparators have little or no state, making them serializable 1270 is generally easy and good defensive programming. 1271 </p> 1272 1273 1274 <h3><a name="SE_INNER_CLASS">Se: Serializable inner class (SE_INNER_CLASS)</a></h3> 1275 1276 1277 <p> This Serializable class is an inner class. Any attempt to serialize 1278 it will also serialize the associated outer instance. The outer instance is serializable, 1279 so this won't fail, but it might serialize a lot more data than intended. 1280 If possible, making the inner class a static inner class (also known as a nested class) should solve the 1281 problem. 1282 1283 1284 <h3><a name="SE_NONFINAL_SERIALVERSIONID">Se: serialVersionUID isn't final (SE_NONFINAL_SERIALVERSIONID)</a></h3> 1285 1286 1287 <p> This class defines a <code>serialVersionUID</code> field that is not final. 1288 The field should be made final 1289 if it is intended to specify 1290 the version UID for purposes of serialization.</p> 1291 1292 1293 <h3><a name="SE_NONLONG_SERIALVERSIONID">Se: serialVersionUID isn't long (SE_NONLONG_SERIALVERSIONID)</a></h3> 1294 1295 1296 <p> This class defines a <code>serialVersionUID</code> field that is not long. 1297 The field should be made long 1298 if it is intended to specify 1299 the version UID for purposes of serialization.</p> 1300 1301 1302 <h3><a name="SE_NONSTATIC_SERIALVERSIONID">Se: serialVersionUID isn't static (SE_NONSTATIC_SERIALVERSIONID)</a></h3> 1303 1304 1305 <p> This class defines a <code>serialVersionUID</code> field that is not static. 1306 The field should be made static 1307 if it is intended to specify 1308 the version UID for purposes of serialization.</p> 1309 1310 1311 <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> 1312 1313 1314 <p> This class implements the <code>Serializable</code> interface 1315 and its superclass does not. When such an object is deserialized, 1316 the fields of the superclass need to be initialized by 1317 invoking the void constructor of the superclass. 1318 Since the superclass does not have one, 1319 serialization and deserialization will fail at runtime.</p> 1320 1321 1322 <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> 1323 1324 1325 <p> This class implements the <code>Externalizable</code> interface, but does 1326 not define a void constructor. When Externalizable objects are deserialized, 1327 they first need to be constructed by invoking the void 1328 constructor. Since this class does not have one, 1329 serialization and deserialization will fail at runtime.</p> 1330 1331 1332 <h3><a name="SE_READ_RESOLVE_MUST_RETURN_OBJECT">Se: The readResolve method must be declared with a return type of Object. (SE_READ_RESOLVE_MUST_RETURN_OBJECT)</a></h3> 1333 1334 1335 <p> In order for the readResolve method to be recognized by the serialization 1336 mechanism, it must be declared to have a return type of Object. 1337 </p> 1338 1339 1340 <h3><a name="SE_TRANSIENT_FIELD_NOT_RESTORED">Se: Transient field that isn't set by deserialization. (SE_TRANSIENT_FIELD_NOT_RESTORED)</a></h3> 1341 1342 1343 <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 1344 deserialized instance of the class. 1345 </p> 1346 1347 1348 <h3><a name="SE_NO_SERIALVERSIONID">SnVI: Class is Serializable, but doesn't define serialVersionUID (SE_NO_SERIALVERSIONID)</a></h3> 1349 1350 1351 <p> This class implements the <code>Serializable</code> interface, but does 1352 not define a <code>serialVersionUID</code> field. 1353 A change as simple as adding a reference to a .class object 1354 will add synthetic fields to the class, 1355 which will unfortunately change the implicit 1356 serialVersionUID (e.g., adding a reference to <code>String.class</code> 1357 will generate a static field <code>class$java$lang$String</code>). 1358 Also, different source code to bytecode compilers may use different 1359 naming conventions for synthetic variables generated for 1360 references to class objects or inner classes. 1361 To ensure interoperability of Serializable across versions, 1362 consider adding an explicit serialVersionUID.</p> 1363 1364 1365 <h3><a name="UI_INHERITANCE_UNSAFE_GETRESOURCE">UI: Usage of GetResource may be unsafe if class is extended (UI_INHERITANCE_UNSAFE_GETRESOURCE)</a></h3> 1366 1367 1368 <p>Calling <code>this.getClass().getResource(...)</code> could give 1369 results other than expected if this class is extended by a class in 1370 another package.</p> 1371 1372 1373 <h3><a name="BC_IMPOSSIBLE_CAST">BC: Impossible cast (BC_IMPOSSIBLE_CAST)</a></h3> 1374 1375 1376 <p> 1377 This cast will always throw a ClassCastException. 1378 FindBugs tracks type information from instanceof checks, 1379 and also uses more precise information about the types 1380 of values returned from methods and loaded from fields. 1381 Thus, it may have more precise information that just 1382 the declared type of a variable, and can use this to determine 1383 that a cast will always throw an exception at runtime. 1384 1385 </p> 1386 1387 1388 <h3><a name="BC_IMPOSSIBLE_DOWNCAST">BC: Impossible downcast (BC_IMPOSSIBLE_DOWNCAST)</a></h3> 1389 1390 1391 <p> 1392 This cast will always throw a ClassCastException. 1393 The analysis believes it knows 1394 the precise type of the value being cast, and the attempt to 1395 downcast it to a subtype will always fail by throwing a ClassCastException. 1396 </p> 1397 1398 1399 <h3><a name="BC_IMPOSSIBLE_DOWNCAST_OF_TOARRAY">BC: Impossible downcast of toArray() result (BC_IMPOSSIBLE_DOWNCAST_OF_TOARRAY)</a></h3> 1400 1401 1402 <p> 1403 This code is casting the result of calling <code>toArray()</code> on a collection 1404 to a type more specific than <code>Object[]</code>, as in:</p> 1405 <pre> 1406 String[] getAsArray(Collection<String> c) { 1407 return (String[]) c.toArray(); 1408 } 1409 </pre> 1410 <p>This will usually fail by throwing a ClassCastException. The <code>toArray()</code> 1411 of almost all collections return an <code>Object[]</code>. They can't really do anything else, 1412 since the Collection object has no reference to the declared generic type of the collection. 1413 <p>The correct way to do get an array of a specific type from a collection is to use 1414 <code>c.toArray(new String[]);</code> 1415 or <code>c.toArray(new String[c.size()]);</code> (the latter is slightly more efficient). 1416 <p>There is one common/known exception exception to this. The <code>toArray()</code> 1417 method of lists returned by <code>Arrays.asList(...)</code> will return a covariantly 1418 typed array. For example, <code>Arrays.asArray(new String[] { "a" }).toArray()</code> 1419 will return a <code>String []</code>. FindBugs attempts to detect and suppress 1420 such cases, but may miss some. 1421 </p> 1422 1423 1424 <h3><a name="BC_IMPOSSIBLE_INSTANCEOF">BC: instanceof will always return false (BC_IMPOSSIBLE_INSTANCEOF)</a></h3> 1425 1426 1427 <p> 1428 This instanceof test will always return false. Although this is safe, make sure it isn't 1429 an indication of some misunderstanding or some other logic error. 1430 </p> 1431 1432 1433 <h3><a name="BIT_ADD_OF_SIGNED_BYTE">BIT: Bitwise add of signed byte value (BIT_ADD_OF_SIGNED_BYTE)</a></h3> 1434 1435 1436 <p> Adds a byte value and a value which is known to have the 8 lower bits clear. 1437 Values loaded from a byte array are sign extended to 32 bits 1438 before any any bitwise operations are performed on the value. 1439 Thus, if <code>b[0]</code> contains the value <code>0xff</code>, and 1440 <code>x</code> is initially 0, then the code 1441 <code>((x << 8) + b[0])</code> will sign extend <code>0xff</code> 1442 to get <code>0xffffffff</code>, and thus give the value 1443 <code>0xffffffff</code> as the result. 1444 </p> 1445 1446 <p>In particular, the following code for packing a byte array into an int is badly wrong: </p> 1447 <pre> 1448 int result = 0; 1449 for(int i = 0; i < 4; i++) 1450 result = ((result << 8) + b[i]); 1451 </pre> 1452 1453 <p>The following idiom will work instead: </p> 1454 <pre> 1455 int result = 0; 1456 for(int i = 0; i < 4; i++) 1457 result = ((result << 8) + (b[i] & 0xff)); 1458 </pre> 1459 1460 1461 1462 <h3><a name="BIT_AND">BIT: Incompatible bit masks (BIT_AND)</a></h3> 1463 1464 1465 <p> This method compares an expression of the form (e & C) to D, 1466 which will always compare unequal 1467 due to the specific values of constants C and D. 1468 This may indicate a logic error or typo.</p> 1469 1470 1471 <h3><a name="BIT_AND_ZZ">BIT: Check to see if ((...) & 0) == 0 (BIT_AND_ZZ)</a></h3> 1472 1473 1474 <p> This method compares an expression of the form (e & 0) to 0, 1475 which will always compare equal. 1476 This may indicate a logic error or typo.</p> 1477 1478 1479 <h3><a name="BIT_IOR">BIT: Incompatible bit masks (BIT_IOR)</a></h3> 1480 1481 1482 <p> This method compares an expression of the form (e | C) to D. 1483 which will always compare unequal 1484 due to the specific values of constants C and D. 1485 This may indicate a logic error or typo.</p> 1486 1487 <p> Typically, this bug occurs because the code wants to perform 1488 a membership test in a bit set, but uses the bitwise OR 1489 operator ("|") instead of bitwise AND ("&").</p> 1490 1491 1492 <h3><a name="BIT_IOR_OF_SIGNED_BYTE">BIT: Bitwise OR of signed byte value (BIT_IOR_OF_SIGNED_BYTE)</a></h3> 1493 1494 1495 <p> Loads a byte value (e.g., a value loaded from a byte array or returned by a method 1496 with return type byte) and performs a bitwise OR with 1497 that value. Byte values are sign extended to 32 bits 1498 before any any bitwise operations are performed on the value. 1499 Thus, if <code>b[0]</code> contains the value <code>0xff</code>, and 1500 <code>x</code> is initially 0, then the code 1501 <code>((x << 8) | b[0])</code> will sign extend <code>0xff</code> 1502 to get <code>0xffffffff</code>, and thus give the value 1503 <code>0xffffffff</code> as the result. 1504 </p> 1505 1506 <p>In particular, the following code for packing a byte array into an int is badly wrong: </p> 1507 <pre> 1508 int result = 0; 1509 for(int i = 0; i < 4; i++) 1510 result = ((result << 8) | b[i]); 1511 </pre> 1512 1513 <p>The following idiom will work instead: </p> 1514 <pre> 1515 int result = 0; 1516 for(int i = 0; i < 4; i++) 1517 result = ((result << 8) | (b[i] & 0xff)); 1518 </pre> 1519 1520 1521 1522 <h3><a name="BIT_SIGNED_CHECK_HIGH_BIT">BIT: Check for sign of bitwise operation (BIT_SIGNED_CHECK_HIGH_BIT)</a></h3> 1523 1524 1525 <p> This method compares an expression such as</p> 1526 <pre>((event.detail & SWT.SELECTED) > 0)</pre>. 1527 <p>Using bit arithmetic and then comparing with the greater than operator can 1528 lead to unexpected results (of course depending on the value of 1529 SWT.SELECTED). If SWT.SELECTED is a negative number, this is a candidate 1530 for a bug. Even when SWT.SELECTED is not negative, it seems good practice 1531 to use '!= 0' instead of '> 0'. 1532 </p> 1533 <p> 1534 <em>Boris Bokowski</em> 1535 </p> 1536 1537 1538 <h3><a name="BOA_BADLY_OVERRIDDEN_ADAPTER">BOA: Class overrides a method implemented in super class Adapter wrongly (BOA_BADLY_OVERRIDDEN_ADAPTER)</a></h3> 1539 1540 1541 <p> This method overrides a method found in a parent class, where that class is an Adapter that implements 1542 a listener defined in the java.awt.event or javax.swing.event package. As a result, this method will not 1543 get called when the event occurs.</p> 1544 1545 1546 <h3><a name="ICAST_BAD_SHIFT_AMOUNT">BSHIFT: 32 bit int shifted by an amount not in the range -31..31 (ICAST_BAD_SHIFT_AMOUNT)</a></h3> 1547 1548 1549 <p> 1550 The code performs shift of a 32 bit int by a constant amount outside 1551 the range -31..31. 1552 The effect of this is to use the lower 5 bits of the integer 1553 value to decide how much to shift by (e.g., shifting by 40 bits is the same as shifting by 8 bits, 1554 and shifting by 32 bits is the same as shifting by zero bits). This probably isn't what was expected, 1555 and it is at least confusing. 1556 </p> 1557 1558 1559 <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> 1560 1561 1562 <p>A wrapped primitive value is unboxed and converted to another primitive type as part of the 1563 evaluation of a conditional ternary operator (the <code> b ? e1 : e2</code> operator). The 1564 semantics of Java mandate that if <code>e1</code> and <code>e2</code> are wrapped 1565 numeric values, the values are unboxed and converted/coerced to their common type (e.g, 1566 if <code>e1</code> is of type <code>Integer</code> 1567 and <code>e2</code> is of type <code>Float</code>, then <code>e1</code> is unboxed, 1568 converted to a floating point value, and boxed. See JLS Section 15.25. 1569 </p> 1570 1571 1572 <h3><a name="CO_COMPARETO_RESULTS_MIN_VALUE">Co: compareTo()/compare() returns Integer.MIN_VALUE (CO_COMPARETO_RESULTS_MIN_VALUE)</a></h3> 1573 1574 1575 <p> In some situation, this compareTo or compare method returns 1576 the constant Integer.MIN_VALUE, which is an exceptionally bad practice. 1577 The only thing that matters about the return value of compareTo is the sign of the result. 1578 But people will sometimes negate the return value of compareTo, expecting that this will negate 1579 the sign of the result. And it will, except in the case where the value returned is Integer.MIN_VALUE. 1580 So just return -1 rather than Integer.MIN_VALUE. 1581 1582 1583 <h3><a name="DLS_DEAD_LOCAL_INCREMENT_IN_RETURN">DLS: Useless increment in return statement (DLS_DEAD_LOCAL_INCREMENT_IN_RETURN)</a></h3> 1584 1585 1586 <p>This statement has a return such as <code>return x++;</code>. 1587 A postfix increment/decrement does not impact the value of the expression, 1588 so this increment/decrement has no effect. 1589 Please verify that this statement does the right thing. 1590 </p> 1591 1592 1593 <h3><a name="DLS_DEAD_STORE_OF_CLASS_LITERAL">DLS: Dead store of class literal (DLS_DEAD_STORE_OF_CLASS_LITERAL)</a></h3> 1594 1595 1596 <p> 1597 This instruction assigns a class literal to a variable and then never uses it. 1598 <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> 1599 In Java 1.4 and earlier, a reference to <code>Foo.class</code> would force the static initializer 1600 for <code>Foo</code> to be executed, if it has not been executed already. 1601 In Java 5 and later, it does not. 1602 </p> 1603 <p>See Sun's <a href="//java.sun.com/j2se/1.5.0/compatibility.html#literal">article on Java SE compatibility</a> 1604 for more details and examples, and suggestions on how to force class initialization in Java 5. 1605 </p> 1606 1607 1608 <h3><a name="DLS_OVERWRITTEN_INCREMENT">DLS: Overwritten increment (DLS_OVERWRITTEN_INCREMENT)</a></h3> 1609 1610 1611 <p> 1612 The code performs an increment operation (e.g., <code>i++</code>) and then 1613 immediately overwrites it. For example, <code>i = i++</code> immediately 1614 overwrites the incremented value with the original value. 1615 </p> 1616 1617 1618 <h3><a name="DMI_ARGUMENTS_WRONG_ORDER">DMI: Reversed method arguments (DMI_ARGUMENTS_WRONG_ORDER)</a></h3> 1619 1620 1621 <p> The arguments to this method call seem to be in the wrong order. 1622 For example, a call <code>Preconditions.checkNotNull("message", message)</code> 1623 has reserved arguments: the value to be checked is the first argument. 1624 </p> 1625 1626 1627 <h3><a name="DMI_BAD_MONTH">DMI: Bad constant value for month (DMI_BAD_MONTH)</a></h3> 1628 1629 1630 <p> 1631 This code passes a constant month 1632 value outside the expected range of 0..11 to a method. 1633 </p> 1634 1635 1636 <h3><a name="DMI_BIGDECIMAL_CONSTRUCTED_FROM_DOUBLE">DMI: BigDecimal constructed from double that isn't represented precisely (DMI_BIGDECIMAL_CONSTRUCTED_FROM_DOUBLE)</a></h3> 1637 1638 1639 <p> 1640 This code creates a BigDecimal from a double value that doesn't translate well to a 1641 decimal number. 1642 For example, one might assume that writing new BigDecimal(0.1) in Java creates a BigDecimal which is exactly equal to 0.1 (an unscaled value of 1, with a scale of 1), but it is actually equal to 0.1000000000000000055511151231257827021181583404541015625. 1643 You probably want to use the BigDecimal.valueOf(double d) method, which uses the String representation 1644 of the double to create the BigDecimal (e.g., BigDecimal.valueOf(0.1) gives 0.1). 1645 </p> 1646 1647 1648 1649 <h3><a name="DMI_CALLING_NEXT_FROM_HASNEXT">DMI: hasNext method invokes next (DMI_CALLING_NEXT_FROM_HASNEXT)</a></h3> 1650 1651 1652 <p> 1653 The hasNext() method invokes the next() method. This is almost certainly wrong, 1654 since the hasNext() method is not supposed to change the state of the iterator, 1655 and the next method is supposed to change the state of the iterator. 1656 </p> 1657 1658 1659 <h3><a name="DMI_COLLECTIONS_SHOULD_NOT_CONTAIN_THEMSELVES">DMI: Collections should not contain themselves (DMI_COLLECTIONS_SHOULD_NOT_CONTAIN_THEMSELVES)</a></h3> 1660 1661 1662 <p> This call to a generic collection's method would only make sense if a collection contained 1663 itself (e.g., if <code>s.contains(s)</code> were true). This is unlikely to be true and would cause 1664 problems if it were true (such as the computation of the hash code resulting in infinite recursion). 1665 It is likely that the wrong value is being passed as a parameter. 1666 </p> 1667 1668 1669 <h3><a name="DMI_DOH">DMI: D'oh! A nonsensical method invocation (DMI_DOH)</a></h3> 1670 1671 1672 <p> 1673 This partical method invocation doesn't make sense, for reasons that should be apparent from inspection. 1674 </p> 1675 1676 1677 1678 <h3><a name="DMI_INVOKING_HASHCODE_ON_ARRAY">DMI: Invocation of hashCode on an array (DMI_INVOKING_HASHCODE_ON_ARRAY)</a></h3> 1679 1680 1681 <p> 1682 The code invokes hashCode on an array. Calling hashCode on 1683 an array returns the same value as System.identityHashCode, and ingores 1684 the contents and length of the array. If you need a hashCode that 1685 depends on the contents of an array <code>a</code>, 1686 use <code>java.util.Arrays.hashCode(a)</code>. 1687 1688 </p> 1689 1690 1691 <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> 1692 1693 1694 <p> The Double.longBitsToDouble method is invoked, but a 32 bit int value is passed 1695 as an argument. This almostly certainly is not intended and is unlikely 1696 to give the intended result. 1697 </p> 1698 1699 1700 <h3><a name="DMI_VACUOUS_SELF_COLLECTION_CALL">DMI: Vacuous call to collections (DMI_VACUOUS_SELF_COLLECTION_CALL)</a></h3> 1701 1702 1703 <p> This call doesn't make sense. For any collection <code>c</code>, calling <code>c.containsAll(c)</code> should 1704 always be true, and <code>c.retainAll(c)</code> should have no effect. 1705 </p> 1706 1707 1708 <h3><a name="DMI_ANNOTATION_IS_NOT_VISIBLE_TO_REFLECTION">Dm: Can't use reflection to check for presence of annotation without runtime retention (DMI_ANNOTATION_IS_NOT_VISIBLE_TO_REFLECTION)</a></h3> 1709 1710 1711 <p> Unless an annotation has itself been annotated with @Retention(RetentionPolicy.RUNTIME), the annotation can't be observed using reflection 1712 (e.g., by using the isAnnotationPresent method). 1713 .</p> 1714 1715 1716 <h3><a name="DMI_FUTILE_ATTEMPT_TO_CHANGE_MAXPOOL_SIZE_OF_SCHEDULED_THREAD_POOL_EXECUTOR">Dm: Futile attempt to change max pool size of ScheduledThreadPoolExecutor (DMI_FUTILE_ATTEMPT_TO_CHANGE_MAXPOOL_SIZE_OF_SCHEDULED_THREAD_POOL_EXECUTOR)</a></h3> 1717 1718 1719 <p>(<a href="http://java.sun.com/javase/6/docs/api/java/util/concurrent/ScheduledThreadPoolExecutor.html">Javadoc</a>) 1720 While ScheduledThreadPoolExecutor inherits from ThreadPoolExecutor, a few of the inherited tuning methods are not useful for it. In particular, because it acts as a fixed-sized pool using corePoolSize threads and an unbounded queue, adjustments to maximumPoolSize have no useful effect. 1721 </p> 1722 1723 1724 1725 <h3><a name="DMI_SCHEDULED_THREAD_POOL_EXECUTOR_WITH_ZERO_CORE_THREADS">Dm: Creation of ScheduledThreadPoolExecutor with zero core threads (DMI_SCHEDULED_THREAD_POOL_EXECUTOR_WITH_ZERO_CORE_THREADS)</a></h3> 1726 1727 1728 <p>(<a href="http://java.sun.com/javase/6/docs/api/java/util/concurrent/ScheduledThreadPoolExecutor.html#ScheduledThreadPoolExecutor(int)">Javadoc</a>) 1729 A ScheduledThreadPoolExecutor with zero core threads will never execute anything; changes to the max pool size are ignored. 1730 </p> 1731 1732 1733 1734 <h3><a name="DMI_VACUOUS_CALL_TO_EASYMOCK_METHOD">Dm: Useless/vacuous call to EasyMock method (DMI_VACUOUS_CALL_TO_EASYMOCK_METHOD)</a></h3> 1735 1736 1737 <p>This call doesn't pass any objects to the EasyMock method, so the call doesn't do anything. 1738 </p> 1739 1740 1741 1742 <h3><a name="EC_ARRAY_AND_NONARRAY">EC: equals() used to compare array and nonarray (EC_ARRAY_AND_NONARRAY)</a></h3> 1743 1744 1745 <p> 1746 This method invokes the .equals(Object o) to compare an array and a reference that doesn't seem 1747 to be an array. If things being compared are of different types, they are guaranteed to be unequal 1748 and the comparison is almost certainly an error. Even if they are both arrays, the equals method 1749 on arrays only determines of the two arrays are the same object. 1750 To compare the 1751 contents of the arrays, use java.util.Arrays.equals(Object[], Object[]). 1752 </p> 1753 1754 1755 <h3><a name="EC_BAD_ARRAY_COMPARE">EC: Invocation of equals() on an array, which is equivalent to == (EC_BAD_ARRAY_COMPARE)</a></h3> 1756 1757 1758 <p> 1759 This method invokes the .equals(Object o) method on an array. Since arrays do not override the equals 1760 method of Object, calling equals on an array is the same as comparing their addresses. To compare the 1761 contents of the arrays, use <code>java.util.Arrays.equals(Object[], Object[])</code>. 1762 To compare the addresses of the arrays, it would be 1763 less confusing to explicitly check pointer equality using <code>==</code>. 1764 </p> 1765 1766 1767 <h3><a name="EC_INCOMPATIBLE_ARRAY_COMPARE">EC: equals(...) used to compare incompatible arrays (EC_INCOMPATIBLE_ARRAY_COMPARE)</a></h3> 1768 1769 1770 <p> 1771 This method invokes the .equals(Object o) to compare two arrays, but the arrays of 1772 of incompatible types (e.g., String[] and StringBuffer[], or String[] and int[]). 1773 They will never be equal. In addition, when equals(...) is used to compare arrays it 1774 only checks to see if they are the same array, and ignores the contents of the arrays. 1775 </p> 1776 1777 1778 <h3><a name="EC_NULL_ARG">EC: Call to equals(null) (EC_NULL_ARG)</a></h3> 1779 1780 1781 <p> This method calls equals(Object), passing a null value as 1782 the argument. According to the contract of the equals() method, 1783 this call should always return <code>false</code>.</p> 1784 1785 1786 <h3><a name="EC_UNRELATED_CLASS_AND_INTERFACE">EC: Call to equals() comparing unrelated class and interface (EC_UNRELATED_CLASS_AND_INTERFACE)</a></h3> 1787 1788 1789 <p> 1790 This method calls equals(Object) on two references, one of which is a class 1791 and the other an interface, where neither the class nor any of its 1792 non-abstract subclasses implement the interface. 1793 Therefore, the objects being compared 1794 are unlikely to be members of the same class at runtime 1795 (unless some application classes were not analyzed, or dynamic class 1796 loading can occur at runtime). 1797 According to the contract of equals(), 1798 objects of different 1799 classes should always compare as unequal; therefore, according to the 1800 contract defined by java.lang.Object.equals(Object), 1801 the result of this comparison will always be false at runtime. 1802 </p> 1803 1804 1805 <h3><a name="EC_UNRELATED_INTERFACES">EC: Call to equals() comparing different interface types (EC_UNRELATED_INTERFACES)</a></h3> 1806 1807 1808 <p> This method calls equals(Object) on two references of unrelated 1809 interface types, where neither is a subtype of the other, 1810 and there are no known non-abstract classes which implement both interfaces. 1811 Therefore, the objects being compared 1812 are unlikely to be members of the same class at runtime 1813 (unless some application classes were not analyzed, or dynamic class 1814 loading can occur at runtime). 1815 According to the contract of equals(), 1816 objects of different 1817 classes should always compare as unequal; therefore, according to the 1818 contract defined by java.lang.Object.equals(Object), 1819 the result of this comparison will always be false at runtime. 1820 </p> 1821 1822 1823 <h3><a name="EC_UNRELATED_TYPES">EC: Call to equals() comparing different types (EC_UNRELATED_TYPES)</a></h3> 1824 1825 1826 <p> This method calls equals(Object) on two references of different 1827 class types with no common subclasses. 1828 Therefore, the objects being compared 1829 are unlikely to be members of the same class at runtime 1830 (unless some application classes were not analyzed, or dynamic class 1831 loading can occur at runtime). 1832 According to the contract of equals(), 1833 objects of different 1834 classes should always compare as unequal; therefore, according to the 1835 contract defined by java.lang.Object.equals(Object), 1836 the result of this comparison will always be false at runtime. 1837 </p> 1838 1839 1840 <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> 1841 1842 1843 <p> This method uses using pointer equality to compare two references that seem to be of 1844 different types. The result of this comparison will always be false at runtime. 1845 </p> 1846 1847 1848 <h3><a name="EQ_ALWAYS_FALSE">Eq: equals method always returns false (EQ_ALWAYS_FALSE)</a></h3> 1849 1850 1851 <p> This class defines an equals method that always returns false. This means that an object is not equal to itself, and it is impossible to create useful Maps or Sets of this class. More fundamentally, it means 1852 that equals is not reflexive, one of the requirements of the equals method.</p> 1853 <p>The likely intended semantics are object identity: that an object is equal to itself. This is the behavior inherited from class <code>Object</code>. If you need to override an equals inherited from a different 1854 superclass, you can use use:</p> 1855 <pre> 1856 public boolean equals(Object o) { return this == o; } 1857 </pre> 1858 1859 1860 <h3><a name="EQ_ALWAYS_TRUE">Eq: equals method always returns true (EQ_ALWAYS_TRUE)</a></h3> 1861 1862 1863 <p> This class defines an equals method that always returns true. This is imaginative, but not very smart. 1864 Plus, it means that the equals method is not symmetric. 1865 </p> 1866 1867 1868 <h3><a name="EQ_COMPARING_CLASS_NAMES">Eq: equals method compares class names rather than class objects (EQ_COMPARING_CLASS_NAMES)</a></h3> 1869 1870 1871 <p> This method checks to see if two objects are the same class by checking to see if the names 1872 of their classes are equal. You can have different classes with the same name if they are loaded by 1873 different class loaders. Just check to see if the class objects are the same. 1874 </p> 1875 1876 1877 <h3><a name="EQ_DONT_DEFINE_EQUALS_FOR_ENUM">Eq: Covariant equals() method defined for enum (EQ_DONT_DEFINE_EQUALS_FOR_ENUM)</a></h3> 1878 1879 1880 <p> This class defines an enumeration, and equality on enumerations are defined 1881 using object identity. Defining a covariant equals method for an enumeration 1882 value is exceptionally bad practice, since it would likely result 1883 in having two different enumeration values that compare as equals using 1884 the covariant enum method, and as not equal when compared normally. 1885 Don't do it. 1886 </p> 1887 1888 1889 <h3><a name="EQ_OTHER_NO_OBJECT">Eq: equals() method defined that doesn't override equals(Object) (EQ_OTHER_NO_OBJECT)</a></h3> 1890 1891 1892 <p> This class defines an <code>equals()</code> 1893 method, that doesn't override the normal <code>equals(Object)</code> method 1894 defined in the base <code>java.lang.Object</code> class. Instead, it 1895 inherits an <code>equals(Object)</code> method from a superclass. 1896 The class should probably define a <code>boolean equals(Object)</code> method. 1897 </p> 1898 1899 1900 <h3><a name="EQ_OTHER_USE_OBJECT">Eq: equals() method defined that doesn't override Object.equals(Object) (EQ_OTHER_USE_OBJECT)</a></h3> 1901 1902 1903 <p> This class defines an <code>equals()</code> 1904 method, that doesn't override the normal <code>equals(Object)</code> method 1905 defined in the base <code>java.lang.Object</code> class. 1906 The class should probably define a <code>boolean equals(Object)</code> method. 1907 </p> 1908 1909 1910 <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> 1911 1912 1913 <p> This class defines an equals method that overrides an equals method in a superclass. Both equals methods 1914 methods use <code>instanceof</code> in the determination of whether two objects are equal. This is fraught with peril, 1915 since it is important that the equals method is symmetrical (in other words, <code>a.equals(b) == b.equals(a)</code>). 1916 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 1917 checks that the argument is an instanceof B, it is quite likely that the equivalence relation defined by these 1918 methods is not symmetric. 1919 </p> 1920 1921 1922 <h3><a name="EQ_SELF_USE_OBJECT">Eq: Covariant equals() method defined, Object.equals(Object) inherited (EQ_SELF_USE_OBJECT)</a></h3> 1923 1924 1925 <p> This class defines a covariant version of the <code>equals()</code> 1926 method, but inherits the normal <code>equals(Object)</code> method 1927 defined in the base <code>java.lang.Object</code> class. 1928 The class should probably define a <code>boolean equals(Object)</code> method. 1929 </p> 1930 1931 1932 <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> 1933 1934 1935 <p> 1936 This code checks to see if a floating point value is equal to the special 1937 Not A Number value (e.g., <code>if (x == Double.NaN)</code>). However, 1938 because of the special semantics of <code>NaN</code>, no value 1939 is equal to <code>Nan</code>, including <code>NaN</code>. Thus, 1940 <code>x == Double.NaN</code> always evaluates to false. 1941 1942 To check to see if a value contained in <code>x</code> 1943 is the special Not A Number value, use 1944 <code>Double.isNaN(x)</code> (or <code>Float.isNaN(x)</code> if 1945 <code>x</code> is floating point precision). 1946 </p> 1947 1948 1949 <h3><a name="VA_FORMAT_STRING_BAD_ARGUMENT">FS: Format string placeholder incompatible with passed argument (VA_FORMAT_STRING_BAD_ARGUMENT)</a></h3> 1950 1951 1952 <p> 1953 The format string placeholder is incompatible with the corresponding 1954 argument. For example, 1955 <code> 1956 System.out.println("%d\n", "hello"); 1957 </code> 1958 <p>The %d placeholder requires a numeric argument, but a string value is 1959 passed instead. 1960 A runtime exception will occur when 1961 this statement is executed. 1962 </p> 1963 1964 1965 <h3><a name="VA_FORMAT_STRING_BAD_CONVERSION">FS: The type of a supplied argument doesn't match format specifier (VA_FORMAT_STRING_BAD_CONVERSION)</a></h3> 1966 1967 1968 <p> 1969 One of the arguments is uncompatible with the corresponding format string specifier. 1970 As a result, this will generate a runtime exception when executed. 1971 For example, <code>String.format("%d", "1")</code> will generate an exception, since 1972 the String "1" is incompatible with the format specifier %d. 1973 </p> 1974 1975 1976 <h3><a name="VA_FORMAT_STRING_EXPECTED_MESSAGE_FORMAT_SUPPLIED">FS: MessageFormat supplied where printf style format expected (VA_FORMAT_STRING_EXPECTED_MESSAGE_FORMAT_SUPPLIED)</a></h3> 1977 1978 1979 <p> 1980 A method is called that expects a Java printf format string and a list of arguments. 1981 However, the format string doesn't contain any format specifiers (e.g., %s) but 1982 does contain message format elements (e.g., {0}). It is likely 1983 that the code is supplying a MessageFormat string when a printf-style format string 1984 is required. At runtime, all of the arguments will be ignored 1985 and the format string will be returned exactly as provided without any formatting. 1986 </p> 1987 1988 1989 <h3><a name="VA_FORMAT_STRING_EXTRA_ARGUMENTS_PASSED">FS: More arguments are passed than are actually used in the format string (VA_FORMAT_STRING_EXTRA_ARGUMENTS_PASSED)</a></h3> 1990 1991 1992 <p> 1993 A format-string method with a variable number of arguments is called, 1994 but more arguments are passed than are actually used by the format string. 1995 This won't cause a runtime exception, but the code may be silently omitting 1996 information that was intended to be included in the formatted string. 1997 </p> 1998 1999 2000 <h3><a name="VA_FORMAT_STRING_ILLEGAL">FS: Illegal format string (VA_FORMAT_STRING_ILLEGAL)</a></h3> 2001 2002 2003 <p> 2004 The format string is syntactically invalid, 2005 and a runtime exception will occur when 2006 this statement is executed. 2007 </p> 2008 2009 2010 <h3><a name="VA_FORMAT_STRING_MISSING_ARGUMENT">FS: Format string references missing argument (VA_FORMAT_STRING_MISSING_ARGUMENT)</a></h3> 2011 2012 2013 <p> 2014 Not enough arguments are passed to satisfy a placeholder in the format string. 2015 A runtime exception will occur when 2016 this statement is executed. 2017 </p> 2018 2019 2020 <h3><a name="VA_FORMAT_STRING_NO_PREVIOUS_ARGUMENT">FS: No previous argument for format string (VA_FORMAT_STRING_NO_PREVIOUS_ARGUMENT)</a></h3> 2021 2022 2023 <p> 2024 The format string specifies a relative index to request that the argument for the previous format specifier 2025 be reused. However, there is no previous argument. 2026 For example, 2027 </p> 2028 <p><code>formatter.format("%<s %s", "a", "b")</code> 2029 </p> 2030 <p>would throw a MissingFormatArgumentException when executed. 2031 </p> 2032 2033 2034 <h3><a name="GC_UNRELATED_TYPES">GC: No relationship between generic parameter and method argument (GC_UNRELATED_TYPES)</a></h3> 2035 2036 2037 <p> This call to a generic collection method contains an argument 2038 with an incompatible class from that of the collection's parameter 2039 (i.e., the type of the argument is neither a supertype nor a subtype 2040 of the corresponding generic type argument). 2041 Therefore, it is unlikely that the collection contains any objects 2042 that are equal to the method argument used here. 2043 Most likely, the wrong value is being passed to the method.</p> 2044 <p>In general, instances of two unrelated classes are not equal. 2045 For example, if the <code>Foo</code> and <code>Bar</code> classes 2046 are not related by subtyping, then an instance of <code>Foo</code> 2047 should not be equal to an instance of <code>Bar</code>. 2048 Among other issues, doing so will likely result in an equals method 2049 that is not symmetrical. For example, if you define the <code>Foo</code> class 2050 so that a <code>Foo</code> can be equal to a <code>String</code>, 2051 your equals method isn't symmetrical since a <code>String</code> can only be equal 2052 to a <code>String</code>. 2053 </p> 2054 <p>In rare cases, people do define nonsymmetrical equals methods and still manage to make 2055 their code work. Although none of the APIs document or guarantee it, it is typically 2056 the case that if you check if a <code>Collection<String></code> contains 2057 a <code>Foo</code>, the equals method of argument (e.g., the equals method of the 2058 <code>Foo</code> class) used to perform the equality checks. 2059 </p> 2060 2061 2062 <h3><a name="HE_SIGNATURE_DECLARES_HASHING_OF_UNHASHABLE_CLASS">HE: Signature declares use of unhashable class in hashed construct (HE_SIGNATURE_DECLARES_HASHING_OF_UNHASHABLE_CLASS)</a></h3> 2063 2064 2065 <p> A method, field or class declares a generic signature where a non-hashable class 2066 is used in context where a hashable class is required. 2067 A class that declares an equals method but inherits a hashCode() method 2068 from Object is unhashable, since it doesn't fulfill the requirement that 2069 equal objects have equal hashCodes. 2070 </p> 2071 2072 2073 <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> 2074 2075 2076 <p> A class defines an equals(Object) method but not a hashCode() method, 2077 and thus doesn't fulfill the requirement that equal objects have equal hashCodes. 2078 An instance of this class is used in a hash data structure, making the need to 2079 fix this problem of highest importance. 2080 2081 2082 <h3><a name="ICAST_INT_2_LONG_AS_INSTANT">ICAST: int value converted to long and used as absolute time (ICAST_INT_2_LONG_AS_INSTANT)</a></h3> 2083 2084 2085 <p> 2086 This code converts a 32-bit int value to a 64-bit long value, and then 2087 passes that value for a method parameter that requires an absolute time value. 2088 An absolute time value is the number 2089 of milliseconds since the standard base time known as "the epoch", namely January 1, 1970, 00:00:00 GMT. 2090 For example, the following method, intended to convert seconds since the epoc into a Date, is badly 2091 broken:</p> 2092 <pre> 2093 Date getDate(int seconds) { return new Date(seconds * 1000); } 2094 </pre> 2095 <p>The multiplication is done using 32-bit arithmetic, and then converted to a 64-bit value. 2096 When a 32-bit value is converted to 64-bits and used to express an absolute time 2097 value, only dates in December 1969 and January 1970 can be represented.</p> 2098 2099 <p>Correct implementations for the above method are:</p> 2100 2101 <pre> 2102 // Fails for dates after 2037 2103 Date getDate(int seconds) { return new Date(seconds * 1000L); } 2104 2105 // better, works for all dates 2106 Date getDate(long seconds) { return new Date(seconds * 1000); } 2107 </pre> 2108 2109 2110 <h3><a name="ICAST_INT_CAST_TO_DOUBLE_PASSED_TO_CEIL">ICAST: Integral value cast to double and then passed to Math.ceil (ICAST_INT_CAST_TO_DOUBLE_PASSED_TO_CEIL)</a></h3> 2111 2112 2113 <p> 2114 This code converts an integral value (e.g., int or long) 2115 to a double precision 2116 floating point number and then 2117 passing the result to the Math.ceil() function, which rounds a double to 2118 the next higher integer value. This operation should always be a no-op, 2119 since the converting an integer to a double should give a number with no fractional part. 2120 It is likely that the operation that generated the value to be passed 2121 to Math.ceil was intended to be performed using double precision 2122 floating point arithmetic. 2123 </p> 2124 2125 2126 2127 <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> 2128 2129 2130 <p> 2131 This code converts an int value to a float precision 2132 floating point number and then 2133 passing the result to the Math.round() function, which returns the int/long closest 2134 to the argument. This operation should always be a no-op, 2135 since the converting an integer to a float should give a number with no fractional part. 2136 It is likely that the operation that generated the value to be passed 2137 to Math.round was intended to be performed using 2138 floating point arithmetic. 2139 </p> 2140 2141 2142 2143 <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> 2144 2145 2146 <p> A JUnit assertion is performed in a run method. Failed JUnit assertions 2147 just result in exceptions being thrown. 2148 Thus, if this exception occurs in a thread other than the thread that invokes 2149 the test method, the exception will terminate the thread but not result 2150 in the test failing. 2151 </p> 2152 2153 2154 <h3><a name="IJU_BAD_SUITE_METHOD">IJU: TestCase declares a bad suite method (IJU_BAD_SUITE_METHOD)</a></h3> 2155 2156 2157 <p> Class is a JUnit TestCase and defines a suite() method. 2158 However, the suite method needs to be declared as either</p> 2159 <pre>public static junit.framework.Test suite()</pre> 2160 or 2161 <pre>public static junit.framework.TestSuite suite()</pre> 2162 2163 2164 <h3><a name="IJU_NO_TESTS">IJU: TestCase has no tests (IJU_NO_TESTS)</a></h3> 2165 2166 2167 <p> Class is a JUnit TestCase but has not implemented any test methods</p> 2168 2169 2170 <h3><a name="IJU_SETUP_NO_SUPER">IJU: TestCase defines setUp that doesn't call super.setUp() (IJU_SETUP_NO_SUPER)</a></h3> 2171 2172 2173 <p> Class is a JUnit TestCase and implements the setUp method. The setUp method should call 2174 super.setUp(), but doesn't.</p> 2175 2176 2177 <h3><a name="IJU_SUITE_NOT_STATIC">IJU: TestCase implements a non-static suite method (IJU_SUITE_NOT_STATIC)</a></h3> 2178 2179 2180 <p> Class is a JUnit TestCase and implements the suite() method. 2181 The suite method should be declared as being static, but isn't.</p> 2182 2183 2184 <h3><a name="IJU_TEARDOWN_NO_SUPER">IJU: TestCase defines tearDown that doesn't call super.tearDown() (IJU_TEARDOWN_NO_SUPER)</a></h3> 2185 2186 2187 <p> Class is a JUnit TestCase and implements the tearDown method. The tearDown method should call 2188 super.tearDown(), but doesn't.</p> 2189 2190 2191 <h3><a name="IL_CONTAINER_ADDED_TO_ITSELF">IL: A collection is added to itself (IL_CONTAINER_ADDED_TO_ITSELF)</a></h3> 2192 2193 2194 <p>A collection is added to itself. As a result, computing the hashCode of this 2195 set will throw a StackOverflowException. 2196 </p> 2197 2198 2199 <h3><a name="IL_INFINITE_LOOP">IL: An apparent infinite loop (IL_INFINITE_LOOP)</a></h3> 2200 2201 2202 <p>This loop doesn't seem to have a way to terminate (other than by perhaps 2203 throwing an exception).</p> 2204 2205 2206 <h3><a name="IL_INFINITE_RECURSIVE_LOOP">IL: An apparent infinite recursive loop (IL_INFINITE_RECURSIVE_LOOP)</a></h3> 2207 2208 2209 <p>This method unconditionally invokes itself. This would seem to indicate 2210 an infinite recursive loop that will result in a stack overflow.</p> 2211 2212 2213 <h3><a name="IM_MULTIPLYING_RESULT_OF_IREM">IM: Integer multiply of result of integer remainder (IM_MULTIPLYING_RESULT_OF_IREM)</a></h3> 2214 2215 2216 <p> 2217 The code multiplies the result of an integer remaining by an integer constant. 2218 Be sure you don't have your operator precedence confused. For example 2219 i % 60 * 1000 is (i % 60) * 1000, not i % (60 * 1000). 2220 </p> 2221 2222 2223 <h3><a name="INT_BAD_COMPARISON_WITH_INT_VALUE">INT: Bad comparison of int value with long constant (INT_BAD_COMPARISON_WITH_INT_VALUE)</a></h3> 2224 2225 2226 <p> This code compares an int value with a long constant that is outside 2227 the range of values that can be represented as an int value. 2228 This comparison is vacuous and possibily to be incorrect. 2229 </p> 2230 2231 2232 <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> 2233 2234 2235 <p> This code compares a value that is guaranteed to be non-negative with a negative constant. 2236 </p> 2237 2238 2239 <h3><a name="INT_BAD_COMPARISON_WITH_SIGNED_BYTE">INT: Bad comparison of signed byte (INT_BAD_COMPARISON_WITH_SIGNED_BYTE)</a></h3> 2240 2241 2242 <p> Signed bytes can only have a value in the range -128 to 127. Comparing 2243 a signed byte with a value outside that range is vacuous and likely to be incorrect. 2244 To convert a signed byte <code>b</code> to an unsigned value in the range 0..255, 2245 use <code>0xff & b</code> 2246 </p> 2247 2248 2249 <h3><a name="IO_APPENDING_TO_OBJECT_OUTPUT_STREAM">IO: Doomed attempt to append to an object output stream (IO_APPENDING_TO_OBJECT_OUTPUT_STREAM)</a></h3> 2250 2251 2252 <p> 2253 This code opens a file in append mode and then wraps the result in an object output stream. 2254 This won't allow you to append to an existing object output stream stored in a file. If you want to be 2255 able to append to an object output stream, you need to keep the object output stream open. 2256 </p> 2257 <p>The only situation in which opening a file in append mode and the writing an object output stream 2258 could work is if on reading the file you plan to open it in random access mode and seek to the byte offset 2259 where the append started. 2260 </p> 2261 2262 <p> 2263 TODO: example. 2264 </p> 2265 2266 2267 <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> 2268 2269 2270 <p> 2271 The initial value of this parameter is ignored, and the parameter 2272 is overwritten here. This often indicates a mistaken belief that 2273 the write to the parameter will be conveyed back to 2274 the caller. 2275 </p> 2276 2277 2278 <h3><a name="MF_CLASS_MASKS_FIELD">MF: Class defines field that masks a superclass field (MF_CLASS_MASKS_FIELD)</a></h3> 2279 2280 2281 <p> This class defines a field with the same name as a visible 2282 instance field in a superclass. This is confusing, and 2283 may indicate an error if methods update or access one of 2284 the fields when they wanted the other.</p> 2285 2286 2287 <h3><a name="MF_METHOD_MASKS_FIELD">MF: Method defines a variable that obscures a field (MF_METHOD_MASKS_FIELD)</a></h3> 2288 2289 2290 <p> This method defines a local variable with the same name as a field 2291 in this class or a superclass. This may cause the method to 2292 read an uninitialized value from the field, leave the field uninitialized, 2293 or both.</p> 2294 2295 2296 <h3><a name="NP_ALWAYS_NULL">NP: Null pointer dereference (NP_ALWAYS_NULL)</a></h3> 2297 2298 2299 <p> A null pointer is dereferenced here. This will lead to a 2300 <code>NullPointerException</code> when the code is executed.</p> 2301 2302 2303 <h3><a name="NP_ALWAYS_NULL_EXCEPTION">NP: Null pointer dereference in method on exception path (NP_ALWAYS_NULL_EXCEPTION)</a></h3> 2304 2305 2306 <p> A pointer which is null on an exception path is dereferenced here. 2307 This will lead to a <code>NullPointerException</code> when the code is executed. 2308 Note that because FindBugs currently does not prune infeasible exception paths, 2309 this may be a false warning.</p> 2310 2311 <p> Also note that FindBugs considers the default case of a switch statement to 2312 be an exception path, since the default case is often infeasible.</p> 2313 2314 2315 <h3><a name="NP_ARGUMENT_MIGHT_BE_NULL">NP: Method does not check for null argument (NP_ARGUMENT_MIGHT_BE_NULL)</a></h3> 2316 2317 2318 <p> 2319 A parameter to this method has been identified as a value that should 2320 always be checked to see whether or not it is null, but it is being dereferenced 2321 without a preceding null check. 2322 </p> 2323 2324 2325 <h3><a name="NP_CLOSING_NULL">NP: close() invoked on a value that is always null (NP_CLOSING_NULL)</a></h3> 2326 2327 2328 <p> close() is being invoked on a value that is always null. If this statement is executed, 2329 a null pointer exception will occur. But the big risk here you never close 2330 something that should be closed. 2331 2332 2333 <h3><a name="NP_GUARANTEED_DEREF">NP: Null value is guaranteed to be dereferenced (NP_GUARANTEED_DEREF)</a></h3> 2334 2335 2336 <p> 2337 There is a statement or branch that if executed guarantees that 2338 a value is null at this point, and that 2339 value that is guaranteed to be dereferenced 2340 (except on forward paths involving runtime exceptions). 2341 </p> 2342 <p>Note that a check such as 2343 <code>if (x == null) throw new NullPointerException();</code> 2344 is treated as a dereference of <code>x</code>. 2345 2346 2347 <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> 2348 2349 2350 <p> 2351 There is a statement or branch on an exception path 2352 that if executed guarantees that 2353 a value is null at this point, and that 2354 value that is guaranteed to be dereferenced 2355 (except on forward paths involving runtime exceptions). 2356 </p> 2357 2358 2359 <h3><a name="NP_NONNULL_FIELD_NOT_INITIALIZED_IN_CONSTRUCTOR">NP: Nonnull field is not initialized (NP_NONNULL_FIELD_NOT_INITIALIZED_IN_CONSTRUCTOR)</a></h3> 2360 2361 2362 <p> The field is marked as nonnull, but isn't written to by the constructor. 2363 The field might be initialized elsewhere during constructor, or might always 2364 be initialized before use. 2365 </p> 2366 2367 2368 <h3><a name="NP_NONNULL_PARAM_VIOLATION">NP: Method call passes null to a nonnull parameter (NP_NONNULL_PARAM_VIOLATION)</a></h3> 2369 2370 2371 <p> 2372 This method passes a null value as the parameter of a method which 2373 must be nonnull. Either this parameter has been explicitly marked 2374 as @Nonnull, or analysis has determined that this parameter is 2375 always dereferenced. 2376 </p> 2377 2378 2379 <h3><a name="NP_NONNULL_RETURN_VIOLATION">NP: Method may return null, but is declared @NonNull (NP_NONNULL_RETURN_VIOLATION)</a></h3> 2380 2381 2382 <p> 2383 This method may return a null value, but the method (or a superclass method 2384 which it overrides) is declared to return @NonNull. 2385 </p> 2386 2387 2388 <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> 2389 2390 2391 <p> 2392 This instanceof test will always return false, since the value being checked is guaranteed to be null. 2393 Although this is safe, make sure it isn't 2394 an indication of some misunderstanding or some other logic error. 2395 </p> 2396 2397 2398 <h3><a name="NP_NULL_ON_SOME_PATH">NP: Possible null pointer dereference (NP_NULL_ON_SOME_PATH)</a></h3> 2399 2400 2401 <p> There is a branch of statement that, <em>if executed,</em> guarantees that 2402 a null value will be dereferenced, which 2403 would generate a <code>NullPointerException</code> when the code is executed. 2404 Of course, the problem might be that the branch or statement is infeasible and that 2405 the null pointer exception can't ever be executed; deciding that is beyond the ability of FindBugs. 2406 </p> 2407 2408 2409 <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> 2410 2411 2412 <p> A reference value which is null on some exception control path is 2413 dereferenced here. This may lead to a <code>NullPointerException</code> 2414 when the code is executed. 2415 Note that because FindBugs currently does not prune infeasible exception paths, 2416 this may be a false warning.</p> 2417 2418 <p> Also note that FindBugs considers the default case of a switch statement to 2419 be an exception path, since the default case is often infeasible.</p> 2420 2421 2422 <h3><a name="NP_NULL_PARAM_DEREF">NP: Method call passes null for nonnull parameter (NP_NULL_PARAM_DEREF)</a></h3> 2423 2424 2425 <p> 2426 This method call passes a null value for a nonnull method parameter. 2427 Either the parameter is annotated as a parameter that should 2428 always be nonnull, or analysis has shown that it will always be 2429 dereferenced. 2430 </p> 2431 2432 2433 <h3><a name="NP_NULL_PARAM_DEREF_ALL_TARGETS_DANGEROUS">NP: Method call passes null for nonnull parameter (NP_NULL_PARAM_DEREF_ALL_TARGETS_DANGEROUS)</a></h3> 2434 2435 2436 <p> 2437 A possibly-null value is passed at a call site where all known 2438 target methods require the parameter to be nonnull. 2439 Either the parameter is annotated as a parameter that should 2440 always be nonnull, or analysis has shown that it will always be 2441 dereferenced. 2442 </p> 2443 2444 2445 <h3><a name="NP_NULL_PARAM_DEREF_NONVIRTUAL">NP: Non-virtual method call passes null for nonnull parameter (NP_NULL_PARAM_DEREF_NONVIRTUAL)</a></h3> 2446 2447 2448 <p> 2449 A possibly-null value is passed to a nonnull method parameter. 2450 Either the parameter is annotated as a parameter that should 2451 always be nonnull, or analysis has shown that it will always be 2452 dereferenced. 2453 </p> 2454 2455 2456 <h3><a name="NP_STORE_INTO_NONNULL_FIELD">NP: Store of null value into field annotated NonNull (NP_STORE_INTO_NONNULL_FIELD)</a></h3> 2457 2458 2459 <p> A value that could be null is stored into a field that has been annotated as NonNull. </p> 2460 2461 2462 <h3><a name="NP_UNWRITTEN_FIELD">NP: Read of unwritten field (NP_UNWRITTEN_FIELD)</a></h3> 2463 2464 2465 <p> The program is dereferencing a field that does not seem to ever have a non-null value written to it. 2466 Unless the field is initialized via some mechanism not seen by the analysis, 2467 dereferencing this value will generate a null pointer exception. 2468 </p> 2469 2470 2471 <h3><a name="NM_BAD_EQUAL">Nm: Class defines equal(Object); should it be equals(Object)? (NM_BAD_EQUAL)</a></h3> 2472 2473 2474 <p> This class defines a method <code>equal(Object)</code>. This method does 2475 not override the <code>equals(Object)</code> method in <code>java.lang.Object</code>, 2476 which is probably what was intended.</p> 2477 2478 2479 <h3><a name="NM_LCASE_HASHCODE">Nm: Class defines hashcode(); should it be hashCode()? (NM_LCASE_HASHCODE)</a></h3> 2480 2481 2482 <p> This class defines a method called <code>hashcode()</code>. This method 2483 does not override the <code>hashCode()</code> method in <code>java.lang.Object</code>, 2484 which is probably what was intended.</p> 2485 2486 2487 <h3><a name="NM_LCASE_TOSTRING">Nm: Class defines tostring(); should it be toString()? (NM_LCASE_TOSTRING)</a></h3> 2488 2489 2490 <p> This class defines a method called <code>tostring()</code>. This method 2491 does not override the <code>toString()</code> method in <code>java.lang.Object</code>, 2492 which is probably what was intended.</p> 2493 2494 2495 <h3><a name="NM_METHOD_CONSTRUCTOR_CONFUSION">Nm: Apparent method/constructor confusion (NM_METHOD_CONSTRUCTOR_CONFUSION)</a></h3> 2496 2497 2498 <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. 2499 If it was intended to be a constructor, remove the declaration of a void return value. 2500 If you had accidently defined this method, realized the mistake, defined a proper constructor 2501 but can't get rid of this method due to backwards compatibility, deprecate the method. 2502 </p> 2503 2504 2505 <h3><a name="NM_VERY_CONFUSING">Nm: Very confusing method names (NM_VERY_CONFUSING)</a></h3> 2506 2507 2508 <p> The referenced methods have names that differ only by capitalization. 2509 This is very confusing because if the capitalization were 2510 identical then one of the methods would override the other. 2511 </p> 2512 2513 2514 <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> 2515 2516 2517 <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 2518 the type of the corresponding parameter in the superclass. For example, if you have:</p> 2519 2520 <blockquote> 2521 <pre> 2522 import alpha.Foo; 2523 public class A { 2524 public int f(Foo x) { return 17; } 2525 } 2526 ---- 2527 import beta.Foo; 2528 public class B extends A { 2529 public int f(Foo x) { return 42; } 2530 } 2531 </pre> 2532 </blockquote> 2533 2534 <p>The <code>f(Foo)</code> method defined in class <code>B</code> doesn't 2535 override the 2536 <code>f(Foo)</code> method defined in class <code>A</code>, because the argument 2537 types are <code>Foo</code>'s from different packages. 2538 </p> 2539 2540 2541 <h3><a name="QBA_QUESTIONABLE_BOOLEAN_ASSIGNMENT">QBA: Method assigns boolean literal in boolean expression (QBA_QUESTIONABLE_BOOLEAN_ASSIGNMENT)</a></h3> 2542 2543 2544 <p> 2545 This method assigns a literal boolean value (true or false) to a boolean variable inside 2546 an if or while expression. Most probably this was supposed to be a boolean comparison using 2547 ==, not an assignment using =. 2548 </p> 2549 2550 2551 <h3><a name="RC_REF_COMPARISON">RC: Suspicious reference comparison (RC_REF_COMPARISON)</a></h3> 2552 2553 2554 <p> This method compares two reference values using the == or != operator, 2555 where the correct way to compare instances of this type is generally 2556 with the equals() method. 2557 It is possible to create distinct instances that are equal but do not compare as == since 2558 they are different objects. 2559 Examples of classes which should generally 2560 not be compared by reference are java.lang.Integer, java.lang.Float, etc.</p> 2561 2562 2563 <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> 2564 2565 2566 <p> A value is checked here to see whether it is null, but this value can't 2567 be null because it was previously dereferenced and if it were null a null pointer 2568 exception would have occurred at the earlier dereference. 2569 Essentially, this code and the previous dereference 2570 disagree as to whether this value is allowed to be null. Either the check is redundant 2571 or the previous dereference is erroneous.</p> 2572 2573 2574 <h3><a name="RE_BAD_SYNTAX_FOR_REGULAR_EXPRESSION">RE: Invalid syntax for regular expression (RE_BAD_SYNTAX_FOR_REGULAR_EXPRESSION)</a></h3> 2575 2576 2577 <p> 2578 The code here uses a regular expression that is invalid according to the syntax 2579 for regular expressions. This statement will throw a PatternSyntaxException when 2580 executed. 2581 </p> 2582 2583 2584 <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> 2585 2586 2587 <p> 2588 The code here uses <code>File.separator</code> 2589 where a regular expression is required. This will fail on Windows 2590 platforms, where the <code>File.separator</code> is a backslash, which is interpreted in a 2591 regular expression as an escape character. Amoung other options, you can just use 2592 <code>File.separatorChar=='\\' ? "\\\\" : File.separator</code> instead of 2593 <code>File.separator</code> 2594 2595 </p> 2596 2597 2598 <h3><a name="RE_POSSIBLE_UNINTENDED_PATTERN">RE: "." or "|" used for regular expression (RE_POSSIBLE_UNINTENDED_PATTERN)</a></h3> 2599 2600 2601 <p> 2602 A String function is being invoked and "." or "|" is being passed 2603 to a parameter that takes a regular expression as an argument. Is this what you intended? 2604 For example 2605 <li>s.replaceAll(".", "/") will return a String in which <em>every</em> character has been replaced by a '/' character 2606 <li>s.split(".") <em>always</em> returns a zero length array of String 2607 <li>"ab|cd".replaceAll("|", "/") will return "/a/b/|/c/d/" 2608 <li>"ab|cd".split("|") will return array with six (!) elements: [, a, b, |, c, d] 2609 </p> 2610 2611 2612 <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> 2613 2614 2615 <p>A random value from 0 to 1 is being coerced to the integer value 0. You probably 2616 want to multiple the random value by something else before coercing it to an integer, or use the <code>Random.nextInt(n)</code> method. 2617 </p> 2618 2619 2620 <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> 2621 2622 2623 <p> This code generates a hashcode and then computes 2624 the absolute value of that hashcode. If the hashcode 2625 is <code>Integer.MIN_VALUE</code>, then the result will be negative as well (since 2626 <code>Math.abs(Integer.MIN_VALUE) == Integer.MIN_VALUE</code>). 2627 </p> 2628 <p>One out of 2^32 strings have a hashCode of Integer.MIN_VALUE, 2629 including "polygenelubricants" "GydZG_" and ""DESIGNING WORKHOUSES". 2630 </p> 2631 2632 2633 <h3><a name="RV_ABSOLUTE_VALUE_OF_RANDOM_INT">RV: Bad attempt to compute absolute value of signed random integer (RV_ABSOLUTE_VALUE_OF_RANDOM_INT)</a></h3> 2634 2635 2636 <p> This code generates a random signed integer and then computes 2637 the absolute value of that random integer. If the number returned by the random number 2638 generator is <code>Integer.MIN_VALUE</code>, then the result will be negative as well (since 2639 <code>Math.abs(Integer.MIN_VALUE) == Integer.MIN_VALUE</code>). (Same problem arised for long values as well). 2640 </p> 2641 2642 2643 <h3><a name="RV_CHECK_COMPARETO_FOR_SPECIFIC_RETURN_VALUE">RV: Code checks for specific values returned by compareTo (RV_CHECK_COMPARETO_FOR_SPECIFIC_RETURN_VALUE)</a></h3> 2644 2645 2646 <p> This code invoked a compareTo or compare method, and checks to see if the return value is a specific value, 2647 such as 1 or -1. When invoking these methods, you should only check the sign of the result, not for any specific 2648 non-zero value. While many or most compareTo and compare methods only return -1, 0 or 1, some of them 2649 will return other values. 2650 2651 2652 <h3><a name="RV_EXCEPTION_NOT_THROWN">RV: Exception created and dropped rather than thrown (RV_EXCEPTION_NOT_THROWN)</a></h3> 2653 2654 2655 <p> This code creates an exception (or error) object, but doesn't do anything with it. For example, 2656 something like </p> 2657 <blockquote> 2658 <pre> 2659 if (x < 0) 2660 new IllegalArgumentException("x must be nonnegative"); 2661 </pre> 2662 </blockquote> 2663 <p>It was probably the intent of the programmer to throw the created exception:</p> 2664 <blockquote> 2665 <pre> 2666 if (x < 0) 2667 throw new IllegalArgumentException("x must be nonnegative"); 2668 </pre> 2669 </blockquote> 2670 2671 2672 <h3><a name="RV_RETURN_VALUE_IGNORED">RV: Method ignores return value (RV_RETURN_VALUE_IGNORED)</a></h3> 2673 2674 2675 <p> The return value of this method should be checked. One common 2676 cause of this warning is to invoke a method on an immutable object, 2677 thinking that it updates the object. For example, in the following code 2678 fragment,</p> 2679 <blockquote> 2680 <pre> 2681 String dateString = getHeaderField(name); 2682 dateString.trim(); 2683 </pre> 2684 </blockquote> 2685 <p>the programmer seems to be thinking that the trim() method will update 2686 the String referenced by dateString. But since Strings are immutable, the trim() 2687 function returns a new String value, which is being ignored here. The code 2688 should be corrected to: </p> 2689 <blockquote> 2690 <pre> 2691 String dateString = getHeaderField(name); 2692 dateString = dateString.trim(); 2693 </pre> 2694 </blockquote> 2695 2696 2697 <h3><a name="RpC_REPEATED_CONDITIONAL_TEST">RpC: Repeated conditional tests (RpC_REPEATED_CONDITIONAL_TEST)</a></h3> 2698 2699 2700 <p>The code contains a conditional test is performed twice, one right after the other 2701 (e.g., <code>x == 0 || x == 0</code>). Perhaps the second occurrence is intended to be something else 2702 (e.g., <code>x == 0 || y == 0</code>). 2703 </p> 2704 2705 2706 <h3><a name="SA_FIELD_SELF_ASSIGNMENT">SA: Self assignment of field (SA_FIELD_SELF_ASSIGNMENT)</a></h3> 2707 2708 2709 <p> This method contains a self assignment of a field; e.g. 2710 </p> 2711 <pre> 2712 int x; 2713 public void foo() { 2714 x = x; 2715 } 2716 </pre> 2717 <p>Such assignments are useless, and may indicate a logic error or typo.</p> 2718 2719 2720 <h3><a name="SA_FIELD_SELF_COMPARISON">SA: Self comparison of field with itself (SA_FIELD_SELF_COMPARISON)</a></h3> 2721 2722 2723 <p> This method compares a field with itself, and may indicate a typo or 2724 a logic error. Make sure that you are comparing the right things. 2725 </p> 2726 2727 2728 <h3><a name="SA_FIELD_SELF_COMPUTATION">SA: Nonsensical self computation involving a field (e.g., x & x) (SA_FIELD_SELF_COMPUTATION)</a></h3> 2729 2730 2731 <p> This method performs a nonsensical computation of a field with another 2732 reference to the same field (e.g., x&x or x-x). Because of the nature 2733 of the computation, this operation doesn't seem to make sense, 2734 and may indicate a typo or 2735 a logic error. Double check the computation. 2736 </p> 2737 2738 2739 <h3><a name="SA_LOCAL_SELF_ASSIGNMENT_INSTEAD_OF_FIELD">SA: Self assignment of local rather than assignment to field (SA_LOCAL_SELF_ASSIGNMENT_INSTEAD_OF_FIELD)</a></h3> 2740 2741 2742 <p> This method contains a self assignment of a local variable, and there 2743 is a field with an identical name. 2744 assignment appears to have been ; e.g.</p> 2745 <pre> 2746 int foo; 2747 public void setFoo(int foo) { 2748 foo = foo; 2749 } 2750 </pre> 2751 <p>The assignment is useless. Did you mean to assign to the field instead?</p> 2752 2753 2754 <h3><a name="SA_LOCAL_SELF_COMPARISON">SA: Self comparison of value with itself (SA_LOCAL_SELF_COMPARISON)</a></h3> 2755 2756 2757 <p> This method compares a local variable with itself, and may indicate a typo or 2758 a logic error. Make sure that you are comparing the right things. 2759 </p> 2760 2761 2762 <h3><a name="SA_LOCAL_SELF_COMPUTATION">SA: Nonsensical self computation involving a variable (e.g., x & x) (SA_LOCAL_SELF_COMPUTATION)</a></h3> 2763 2764 2765 <p> This method performs a nonsensical computation of a local variable with another 2766 reference to the same variable (e.g., x&x or x-x). Because of the nature 2767 of the computation, this operation doesn't seem to make sense, 2768 and may indicate a typo or 2769 a logic error. Double check the computation. 2770 </p> 2771 2772 2773 <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> 2774 2775 2776 <p> A value stored in the previous switch case is overwritten here due to a switch fall through. It is likely that 2777 you forgot to put a break or return at the end of the previous case. 2778 </p> 2779 2780 2781 <h3><a name="SF_DEAD_STORE_DUE_TO_SWITCH_FALLTHROUGH_TO_THROW">SF: Dead store due to switch statement fall through to throw (SF_DEAD_STORE_DUE_TO_SWITCH_FALLTHROUGH_TO_THROW)</a></h3> 2782 2783 2784 <p> A value stored in the previous switch case is ignored here due to a switch fall through to a place where 2785 an exception is thrown. It is likely that 2786 you forgot to put a break or return at the end of the previous case. 2787 </p> 2788 2789 2790 <h3><a name="SIC_THREADLOCAL_DEADLY_EMBRACE">SIC: Deadly embrace of non-static inner class and thread local (SIC_THREADLOCAL_DEADLY_EMBRACE)</a></h3> 2791 2792 2793 <p> This class is an inner class, but should probably be a static inner class. 2794 As it is, there is a serious danger of a deadly embrace between the inner class 2795 and the thread local in the outer class. Because the inner class isn't static, 2796 it retains a reference to the outer class. 2797 If the thread local contains a reference to an instance of the inner 2798 class, the inner and outer instance will both be reachable 2799 and not eligible for garbage collection. 2800 </p> 2801 2802 2803 <h3><a name="SIO_SUPERFLUOUS_INSTANCEOF">SIO: Unnecessary type check done using instanceof operator (SIO_SUPERFLUOUS_INSTANCEOF)</a></h3> 2804 2805 2806 <p> Type check performed using the instanceof operator where it can be statically determined whether the object 2807 is of the type requested. </p> 2808 2809 2810 <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> 2811 2812 2813 <p> A call to a setXXX method of a prepared statement was made where the 2814 parameter index is 0. As parameter indexes start at index 1, this is always a mistake.</p> 2815 2816 2817 <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> 2818 2819 2820 <p> A call to getXXX or updateXXX methods of a result set was made where the 2821 field index is 0. As ResultSet fields start at index 1, this is always a mistake.</p> 2822 2823 2824 <h3><a name="STI_INTERRUPTED_ON_CURRENTTHREAD">STI: Unneeded use of currentThread() call, to call interrupted() (STI_INTERRUPTED_ON_CURRENTTHREAD)</a></h3> 2825 2826 2827 <p> 2828 This method invokes the Thread.currentThread() call, just to call the interrupted() method. As interrupted() is a 2829 static method, is more simple and clear to use Thread.interrupted(). 2830 </p> 2831 2832 2833 <h3><a name="STI_INTERRUPTED_ON_UNKNOWNTHREAD">STI: Static Thread.interrupted() method invoked on thread instance (STI_INTERRUPTED_ON_UNKNOWNTHREAD)</a></h3> 2834 2835 2836 <p> 2837 This method invokes the Thread.interrupted() method on a Thread object that appears to be a Thread object that is 2838 not the current thread. As the interrupted() method is static, the interrupted method will be called on a different 2839 object than the one the author intended. 2840 </p> 2841 2842 2843 <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> 2844 2845 2846 <p> This class implements the <code>Serializable</code> interface, and defines a method 2847 for custom serialization/deserialization. But since that method isn't declared private, 2848 it will be silently ignored by the serialization/deserialization API.</p> 2849 2850 2851 <h3><a name="SE_READ_RESOLVE_IS_STATIC">Se: The readResolve method must not be declared as a static method. (SE_READ_RESOLVE_IS_STATIC)</a></h3> 2852 2853 2854 <p> In order for the readResolve method to be recognized by the serialization 2855 mechanism, it must not be declared as a static method. 2856 </p> 2857 2858 2859 <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> 2860 2861 2862 <p> 2863 A value specified as carrying a type qualifier annotation is 2864 consumed in a location or locations requiring that the value not 2865 carry that annotation. 2866 </p> 2867 2868 <p> 2869 More precisely, a value annotated with a type qualifier specifying when=ALWAYS 2870 is guaranteed to reach a use or uses where the same type qualifier specifies when=NEVER. 2871 </p> 2872 2873 <p> 2874 For example, say that @NonNegative is a nickname for 2875 the type qualifier annotation @Negative(when=When.NEVER). 2876 The following code will generate this warning because 2877 the return statement requires a @NonNegative value, 2878 but receives one that is marked as @Negative. 2879 </p> 2880 <blockquote> 2881 <pre> 2882 public @NonNegative Integer example(@Negative Integer value) { 2883 return value; 2884 } 2885 </pre> 2886 </blockquote> 2887 2888 2889 <h3><a name="TQ_COMPARING_VALUES_WITH_INCOMPATIBLE_TYPE_QUALIFIERS">TQ: Comparing values with incompatible type qualifiers (TQ_COMPARING_VALUES_WITH_INCOMPATIBLE_TYPE_QUALIFIERS)</a></h3> 2890 2891 2892 <p> 2893 A value specified as carrying a type qualifier annotation is 2894 compared with a value that doesn't ever carry that qualifier. 2895 </p> 2896 2897 <p> 2898 More precisely, a value annotated with a type qualifier specifying when=ALWAYS 2899 is compared with a value that where the same type qualifier specifies when=NEVER. 2900 </p> 2901 2902 <p> 2903 For example, say that @NonNegative is a nickname for 2904 the type qualifier annotation @Negative(when=When.NEVER). 2905 The following code will generate this warning because 2906 the return statement requires a @NonNegative value, 2907 but receives one that is marked as @Negative. 2908 </p> 2909 <blockquote> 2910 <pre> 2911 public boolean example(@Negative Integer value1, @NonNegative Integer value2) { 2912 return value1.equals(value2); 2913 } 2914 </pre> 2915 </blockquote> 2916 2917 2918 <h3><a name="TQ_MAYBE_SOURCE_VALUE_REACHES_ALWAYS_SINK">TQ: Value that might not carry a type qualifier is always used in a way requires that type qualifier (TQ_MAYBE_SOURCE_VALUE_REACHES_ALWAYS_SINK)</a></h3> 2919 2920 2921 <p> 2922 A value that is annotated as possibility not being an instance of 2923 the values denoted by the type qualifier, and the value is guaranteed to be used 2924 in a way that requires values denoted by that type qualifier. 2925 </p> 2926 2927 2928 <h3><a name="TQ_MAYBE_SOURCE_VALUE_REACHES_NEVER_SINK">TQ: Value that might carry a type qualifier is always used in a way prohibits it from having that type qualifier (TQ_MAYBE_SOURCE_VALUE_REACHES_NEVER_SINK)</a></h3> 2929 2930 2931 <p> 2932 A value that is annotated as possibility being an instance of 2933 the values denoted by the type qualifier, and the value is guaranteed to be used 2934 in a way that prohibits values denoted by that type qualifier. 2935 </p> 2936 2937 2938 <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> 2939 2940 2941 <p> 2942 A value specified as not carrying a type qualifier annotation is guaranteed 2943 to be consumed in a location or locations requiring that the value does 2944 carry that annotation. 2945 </p> 2946 2947 <p> 2948 More precisely, a value annotated with a type qualifier specifying when=NEVER 2949 is guaranteed to reach a use or uses where the same type qualifier specifies when=ALWAYS. 2950 </p> 2951 2952 <p> 2953 TODO: example 2954 </p> 2955 2956 2957 <h3><a name="TQ_UNKNOWN_VALUE_USED_WHERE_ALWAYS_STRICTLY_REQUIRED">TQ: Value without a type qualifier used where a value is required to have that qualifier (TQ_UNKNOWN_VALUE_USED_WHERE_ALWAYS_STRICTLY_REQUIRED)</a></h3> 2958 2959 2960 <p> 2961 A value is being used in a way that requires the value be annotation with a type qualifier. 2962 The type qualifier is strict, so the tool rejects any values that do not have 2963 the appropriate annotation. 2964 </p> 2965 2966 <p> 2967 To coerce a value to have a strict annotation, define an identity function where the return value is annotated 2968 with the strict annotation. 2969 This is the only way to turn a non-annotated value into a value with a strict type qualifier annotation. 2970 </p> 2971 2972 2973 2974 <h3><a name="UMAC_UNCALLABLE_METHOD_OF_ANONYMOUS_CLASS">UMAC: Uncallable method defined in anonymous class (UMAC_UNCALLABLE_METHOD_OF_ANONYMOUS_CLASS)</a></h3> 2975 2976 2977 <p> This anonymous class defined a method that is not directly invoked and does not override 2978 a method in a superclass. Since methods in other classes cannot directly invoke methods 2979 declared in an anonymous class, it seems that this method is uncallable. The method 2980 might simply be dead code, but it is also possible that the method is intended to 2981 override a method declared in a superclass, and due to an typo or other error the method does not, 2982 in fact, override the method it is intended to. 2983 </p> 2984 2985 2986 <h3><a name="UR_UNINIT_READ">UR: Uninitialized read of field in constructor (UR_UNINIT_READ)</a></h3> 2987 2988 2989 <p> This constructor reads a field which has not yet been assigned a value. 2990 This is often caused when the programmer mistakenly uses the field instead 2991 of one of the constructor's parameters.</p> 2992 2993 2994 <h3><a name="UR_UNINIT_READ_CALLED_FROM_SUPER_CONSTRUCTOR">UR: Uninitialized read of field method called from constructor of superclass (UR_UNINIT_READ_CALLED_FROM_SUPER_CONSTRUCTOR)</a></h3> 2995 2996 2997 <p> This method is invoked in the constructor of of the superclass. At this point, 2998 the fields of the class have not yet initialized.</p> 2999 <p>To make this more concrete, consider the following classes:</p> 3000 <pre>abstract class A { 3001 int hashCode; 3002 abstract Object getValue(); 3003 A() { 3004 hashCode = getValue().hashCode(); 3005 } 3006 } 3007 class B extends A { 3008 Object value; 3009 B(Object v) { 3010 this.value = v; 3011 } 3012 Object getValue() { 3013 return value; 3014 } 3015 }</pre> 3016 <p>When a <code>B</code> is constructed, 3017 the constructor for the <code>A</code> class is invoked 3018 <em>before</em> the constructor for <code>B</code> sets <code>value</code>. 3019 Thus, when the constructor for <code>A</code> invokes <code>getValue</code>, 3020 an uninitialized value is read for <code>value</code> 3021 </p> 3022 3023 3024 <h3><a name="DMI_INVOKING_TOSTRING_ON_ANONYMOUS_ARRAY">USELESS_STRING: Invocation of toString on an unnamed array (DMI_INVOKING_TOSTRING_ON_ANONYMOUS_ARRAY)</a></h3> 3025 3026 3027 <p> 3028 The code invokes toString on an (anonymous) array. Calling toString on an array generates a fairly useless result 3029 such as [C@16f0472. Consider using Arrays.toString to convert the array into a readable 3030 String that gives the contents of the array. See Programming Puzzlers, chapter 3, puzzle 12. 3031 </p> 3032 3033 3034 <h3><a name="DMI_INVOKING_TOSTRING_ON_ARRAY">USELESS_STRING: Invocation of toString on an array (DMI_INVOKING_TOSTRING_ON_ARRAY)</a></h3> 3035 3036 3037 <p> 3038 The code invokes toString on an array, which will generate a fairly useless result 3039 such as [C@16f0472. Consider using Arrays.toString to convert the array into a readable 3040 String that gives the contents of the array. See Programming Puzzlers, chapter 3, puzzle 12. 3041 </p> 3042 3043 3044 <h3><a name="VA_FORMAT_STRING_BAD_CONVERSION_FROM_ARRAY">USELESS_STRING: Array formatted in useless way using format string (VA_FORMAT_STRING_BAD_CONVERSION_FROM_ARRAY)</a></h3> 3045 3046 3047 <p> 3048 One of the arguments being formatted with a format string is an array. This will be formatted 3049 using a fairly useless format, such as [I@304282, which doesn't actually show the contents 3050 of the array. 3051 Consider wrapping the array using <code>Arrays.asList(...)</code> before handling it off to a formatted. 3052 </p> 3053 3054 3055 <h3><a name="UWF_NULL_FIELD">UwF: Field only ever set to null (UWF_NULL_FIELD)</a></h3> 3056 3057 3058 <p> All writes to this field are of the constant value null, and thus 3059 all reads of the field will return null. 3060 Check for errors, or remove it if it is useless.</p> 3061 3062 3063 <h3><a name="UWF_UNWRITTEN_FIELD">UwF: Unwritten field (UWF_UNWRITTEN_FIELD)</a></h3> 3064 3065 3066 <p> This field is never written. All reads of it will return the default 3067 value. Check for errors (should it have been initialized?), or remove it if it is useless.</p> 3068 3069 3070 <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> 3071 3072 3073 <p> 3074 This code passes a primitive array to a function that takes a variable number of object arguments. 3075 This creates an array of length one to hold the primitive array and passes it to the function. 3076 </p> 3077 3078 3079 <h3><a name="LG_LOST_LOGGER_DUE_TO_WEAK_REFERENCE">LG: Potential lost logger changes due to weak reference in OpenJDK (LG_LOST_LOGGER_DUE_TO_WEAK_REFERENCE)</a></h3> 3080 3081 3082 <p>OpenJDK introduces a potential incompatibility. 3083 In particular, the java.util.logging.Logger behavior has 3084 changed. Instead of using strong references, it now uses weak references 3085 internally. That's a reasonable change, but unfortunately some code relies on 3086 the old behavior - when changing logger configuration, it simply drops the 3087 logger reference. That means that the garbage collector is free to reclaim 3088 that memory, which means that the logger configuration is lost. For example, 3089 consider: 3090 </p> 3091 3092 <pre>public static void initLogging() throws Exception { 3093 Logger logger = Logger.getLogger("edu.umd.cs"); 3094 logger.addHandler(new FileHandler()); // call to change logger configuration 3095 logger.setUseParentHandlers(false); // another call to change logger configuration 3096 }</pre> 3097 3098 <p>The logger reference is lost at the end of the method (it doesn't 3099 escape the method), so if you have a garbage collection cycle just 3100 after the call to initLogging, the logger configuration is lost 3101 (because Logger only keeps weak references).</p> 3102 3103 <pre>public static void main(String[] args) throws Exception { 3104 initLogging(); // adds a file handler to the logger 3105 System.gc(); // logger configuration lost 3106 Logger.getLogger("edu.umd.cs").info("Some message"); // this isn't logged to the file as expected 3107 }</pre> 3108 <p><em>Ulf Ochsenfahrt and Eric Fellheimer</em></p> 3109 3110 3111 <h3><a name="OBL_UNSATISFIED_OBLIGATION">OBL: Method may fail to clean up stream or resource (OBL_UNSATISFIED_OBLIGATION)</a></h3> 3112 3113 3114 <p> 3115 This method may fail to clean up (close, dispose of) a stream, 3116 database object, or other 3117 resource requiring an explicit cleanup operation. 3118 </p> 3119 3120 <p> 3121 In general, if a method opens a stream or other resource, 3122 the method should use a try/finally block to ensure that 3123 the stream or resource is cleaned up before the method 3124 returns. 3125 </p> 3126 3127 <p> 3128 This bug pattern is essentially the same as the 3129 OS_OPEN_STREAM and ODR_OPEN_DATABASE_RESOURCE 3130 bug patterns, but is based on a different 3131 (and hopefully better) static analysis technique. 3132 We are interested is getting feedback about the 3133 usefulness of this bug pattern. 3134 To send feedback, either: 3135 </p> 3136 <ul> 3137 <li>send email to findbugs (a] cs.umd.edu</li> 3138 <li>file a bug report: <a href="http://findbugs.sourceforge.net/reportingBugs.html">http://findbugs.sourceforge.net/reportingBugs.html</a></li> 3139 </ul> 3140 3141 <p> 3142 In particular, 3143 the false-positive suppression heuristics for this 3144 bug pattern have not been extensively tuned, so 3145 reports about false positives are helpful to us. 3146 </p> 3147 3148 <p> 3149 See Weimer and Necula, <i>Finding and Preventing Run-Time Error Handling Mistakes</i>, for 3150 a description of the analysis technique. 3151 </p> 3152 3153 3154 <h3><a name="OBL_UNSATISFIED_OBLIGATION_EXCEPTION_EDGE">OBL: Method may fail to clean up stream or resource on checked exception (OBL_UNSATISFIED_OBLIGATION_EXCEPTION_EDGE)</a></h3> 3155 3156 3157 <p> 3158 This method may fail to clean up (close, dispose of) a stream, 3159 database object, or other 3160 resource requiring an explicit cleanup operation. 3161 </p> 3162 3163 <p> 3164 In general, if a method opens a stream or other resource, 3165 the method should use a try/finally block to ensure that 3166 the stream or resource is cleaned up before the method 3167 returns. 3168 </p> 3169 3170 <p> 3171 This bug pattern is essentially the same as the 3172 OS_OPEN_STREAM and ODR_OPEN_DATABASE_RESOURCE 3173 bug patterns, but is based on a different 3174 (and hopefully better) static analysis technique. 3175 We are interested is getting feedback about the 3176 usefulness of this bug pattern. 3177 To send feedback, either: 3178 </p> 3179 <ul> 3180 <li>send email to findbugs (a] cs.umd.edu</li> 3181 <li>file a bug report: <a href="http://findbugs.sourceforge.net/reportingBugs.html">http://findbugs.sourceforge.net/reportingBugs.html</a></li> 3182 </ul> 3183 3184 <p> 3185 In particular, 3186 the false-positive suppression heuristics for this 3187 bug pattern have not been extensively tuned, so 3188 reports about false positives are helpful to us. 3189 </p> 3190 3191 <p> 3192 See Weimer and Necula, <i>Finding and Preventing Run-Time Error Handling Mistakes</i>, for 3193 a description of the analysis technique. 3194 </p> 3195 3196 3197 <h3><a name="DM_CONVERT_CASE">Dm: Consider using Locale parameterized version of invoked method (DM_CONVERT_CASE)</a></h3> 3198 3199 3200 <p> A String is being converted to upper or lowercase, using the platform's default encoding. This may 3201 result in improper conversions when used with international characters. Use the </p> 3202 <ul> 3203 <li>String.toUpperCase( Locale l )</li> 3204 <li>String.toLowerCase( Locale l )</li> 3205 </ul> 3206 <p>versions instead.</p> 3207 3208 3209 <h3><a name="DM_DEFAULT_ENCODING">Dm: Reliance on default encoding (DM_DEFAULT_ENCODING)</a></h3> 3210 3211 3212 <p> Found a call to a method which will perform a byte to String (or String to byte) conversion, and will assume that the default platform encoding is suitable. This will cause the application behaviour to vary between platforms. Use an alternative API and specify a charset name or Charset object explicitly. </p> 3213 3214 3215 <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> 3216 3217 3218 <p> This code creates a classloader, which needs permission if a security manage is installed. 3219 If this code might be invoked by code that does not 3220 have security permissions, then the classloader creation needs to occur inside a doPrivileged block.</p> 3221 3222 3223 <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> 3224 3225 3226 <p> This code invokes a method that requires a security permission check. 3227 If this code will be granted security permissions, but might be invoked by code that does not 3228 have security permissions, then the invocation needs to occur inside a doPrivileged block.</p> 3229 3230 3231 <h3><a name="EI_EXPOSE_REP">EI: May expose internal representation by returning reference to mutable object (EI_EXPOSE_REP)</a></h3> 3232 3233 3234 <p> Returning a reference to a mutable object value stored in one of the object's fields 3235 exposes the internal representation of the object. 3236 If instances 3237 are accessed by untrusted code, and unchecked changes to 3238 the mutable object would compromise security or other 3239 important properties, you will need to do something different. 3240 Returning a new copy of the object is better approach in many situations.</p> 3241 3242 3243 <h3><a name="EI_EXPOSE_REP2">EI2: May expose internal representation by incorporating reference to mutable object (EI_EXPOSE_REP2)</a></h3> 3244 3245 3246 <p> This code stores a reference to an externally mutable object into the 3247 internal representation of the object. 3248 If instances 3249 are accessed by untrusted code, and unchecked changes to 3250 the mutable object would compromise security or other 3251 important properties, you will need to do something different. 3252 Storing a copy of the object is better approach in many situations.</p> 3253 3254 3255 <h3><a name="FI_PUBLIC_SHOULD_BE_PROTECTED">FI: Finalizer should be protected, not public (FI_PUBLIC_SHOULD_BE_PROTECTED)</a></h3> 3256 3257 3258 <p> A class's <code>finalize()</code> method should have protected access, 3259 not public.</p> 3260 3261 3262 <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> 3263 3264 3265 <p> This code stores a reference to an externally mutable object into a static 3266 field. 3267 If unchecked changes to 3268 the mutable object would compromise security or other 3269 important properties, you will need to do something different. 3270 Storing a copy of the object is better approach in many situations.</p> 3271 3272 3273 <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> 3274 3275 3276 <p> 3277 A mutable static field could be changed by malicious code or 3278 by accident from another package. 3279 Unfortunately, the way the field is used doesn't allow 3280 any easy fix to this problem.</p> 3281 3282 3283 <h3><a name="MS_EXPOSE_REP">MS: Public static method may expose internal representation by returning array (MS_EXPOSE_REP)</a></h3> 3284 3285 3286 <p> A public static method returns a reference to 3287 an array that is part of the static state of the class. 3288 Any code that calls this method can freely modify 3289 the underlying array. 3290 One fix is to return a copy of the array.</p> 3291 3292 3293 <h3><a name="MS_FINAL_PKGPROTECT">MS: Field should be both final and package protected (MS_FINAL_PKGPROTECT)</a></h3> 3294 3295 3296 <p> 3297 A mutable static field could be changed by malicious code or 3298 by accident from another package. 3299 The field could be made package protected and/or made final 3300 to avoid 3301 this vulnerability.</p> 3302 3303 3304 <h3><a name="MS_MUTABLE_ARRAY">MS: Field is a mutable array (MS_MUTABLE_ARRAY)</a></h3> 3305 3306 3307 <p> A final static field references an array 3308 and can be accessed by malicious code or 3309 by accident from another package. 3310 This code can freely modify the contents of the array.</p> 3311 3312 3313 <h3><a name="MS_MUTABLE_HASHTABLE">MS: Field is a mutable Hashtable (MS_MUTABLE_HASHTABLE)</a></h3> 3314 3315 3316 <p>A final static field references a Hashtable 3317 and can be accessed by malicious code or 3318 by accident from another package. 3319 This code can freely modify the contents of the Hashtable.</p> 3320 3321 3322 <h3><a name="MS_OOI_PKGPROTECT">MS: Field should be moved out of an interface and made package protected (MS_OOI_PKGPROTECT)</a></h3> 3323 3324 3325 <p> 3326 A final static field that is 3327 defined in an interface references a mutable 3328 object such as an array or hashtable. 3329 This mutable object could 3330 be changed by malicious code or 3331 by accident from another package. 3332 To solve this, the field needs to be moved to a class 3333 and made package protected 3334 to avoid 3335 this vulnerability.</p> 3336 3337 3338 <h3><a name="MS_PKGPROTECT">MS: Field should be package protected (MS_PKGPROTECT)</a></h3> 3339 3340 3341 <p> A mutable static field could be changed by malicious code or 3342 by accident. 3343 The field could be made package protected to avoid 3344 this vulnerability.</p> 3345 3346 3347 <h3><a name="MS_SHOULD_BE_FINAL">MS: Field isn't final but should be (MS_SHOULD_BE_FINAL)</a></h3> 3348 3349 3350 <p> 3351 This static field public but not final, and 3352 could be changed by malicious code or 3353 by accident from another package. 3354 The field could be made final to avoid 3355 this vulnerability.</p> 3356 3357 3358 <h3><a name="MS_SHOULD_BE_REFACTORED_TO_BE_FINAL">MS: Field isn't final but should be refactored to be so (MS_SHOULD_BE_REFACTORED_TO_BE_FINAL)</a></h3> 3359 3360 3361 <p> 3362 This static field public but not final, and 3363 could be changed by malicious code or 3364 by accident from another package. 3365 The field could be made final to avoid 3366 this vulnerability. However, the static initializer contains more than one write 3367 to the field, so doing so will require some refactoring. 3368 </p> 3369 3370 3371 <h3><a name="AT_OPERATION_SEQUENCE_ON_CONCURRENT_ABSTRACTION">AT: Sequence of calls to concurrent abstraction may not be atomic (AT_OPERATION_SEQUENCE_ON_CONCURRENT_ABSTRACTION)</a></h3> 3372 3373 3374 <p>This code contains a sequence of calls to a concurrent abstraction 3375 (such as a concurrent hash map). 3376 These calls will not be executed atomically. 3377 3378 3379 <h3><a name="DC_DOUBLECHECK">DC: Possible double check of field (DC_DOUBLECHECK)</a></h3> 3380 3381 3382 <p> This method may contain an instance of double-checked locking. 3383 This idiom is not correct according to the semantics of the Java memory 3384 model. For more information, see the web page 3385 <a href="http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html" 3386 >http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html</a>.</p> 3387 3388 3389 <h3><a name="DL_SYNCHRONIZATION_ON_BOOLEAN">DL: Synchronization on Boolean (DL_SYNCHRONIZATION_ON_BOOLEAN)</a></h3> 3390 3391 3392 <p> The code synchronizes on a boxed primitive constant, such as an Boolean.</p> 3393 <pre> 3394 private static Boolean inited = Boolean.FALSE; 3395 ... 3396 synchronized(inited) { 3397 if (!inited) { 3398 init(); 3399 inited = Boolean.TRUE; 3400 } 3401 } 3402 ... 3403 </pre> 3404 <p>Since there normally exist only two Boolean objects, this code could be synchronizing on the same object as other, unrelated code, leading to unresponsiveness 3405 and possible deadlock</p> 3406 <p>See CERT <a href="https://www.securecoding.cert.org/confluence/display/java/CON08-J.+Do+not+synchronize+on+objects+that+may+be+reused">CON08-J. Do not synchronize on objects that may be reused</a> for more information.</p> 3407 3408 3409 <h3><a name="DL_SYNCHRONIZATION_ON_BOXED_PRIMITIVE">DL: Synchronization on boxed primitive (DL_SYNCHRONIZATION_ON_BOXED_PRIMITIVE)</a></h3> 3410 3411 3412 <p> The code synchronizes on a boxed primitive constant, such as an Integer.</p> 3413 <pre> 3414 private static Integer count = 0; 3415 ... 3416 synchronized(count) { 3417 count++; 3418 } 3419 ... 3420 </pre> 3421 <p>Since Integer objects can be cached and shared, 3422 this code could be synchronizing on the same object as other, unrelated code, leading to unresponsiveness 3423 and possible deadlock</p> 3424 <p>See CERT <a href="https://www.securecoding.cert.org/confluence/display/java/CON08-J.+Do+not+synchronize+on+objects+that+may+be+reused">CON08-J. Do not synchronize on objects that may be reused</a> for more information.</p> 3425 3426 3427 <h3><a name="DL_SYNCHRONIZATION_ON_SHARED_CONSTANT">DL: Synchronization on interned String (DL_SYNCHRONIZATION_ON_SHARED_CONSTANT)</a></h3> 3428 3429 3430 <p> The code synchronizes on interned String.</p> 3431 <pre> 3432 private static String LOCK = "LOCK"; 3433 ... 3434 synchronized(LOCK) { ...} 3435 ... 3436 </pre> 3437 <p>Constant Strings are interned and shared across all other classes loaded by the JVM. Thus, this could 3438 is locking on something that other code might also be locking. This could result in very strange and hard to diagnose 3439 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>. 3440 </p> 3441 <p>See CERT <a href="https://www.securecoding.cert.org/confluence/display/java/CON08-J.+Do+not+synchronize+on+objects+that+may+be+reused">CON08-J. Do not synchronize on objects that may be reused</a> for more information.</p> 3442 3443 3444 <h3><a name="DL_SYNCHRONIZATION_ON_UNSHARED_BOXED_PRIMITIVE">DL: Synchronization on boxed primitive values (DL_SYNCHRONIZATION_ON_UNSHARED_BOXED_PRIMITIVE)</a></h3> 3445 3446 3447 <p> The code synchronizes on an apparently unshared boxed primitive, 3448 such as an Integer.</p> 3449 <pre> 3450 private static final Integer fileLock = new Integer(1); 3451 ... 3452 synchronized(fileLock) { 3453 .. do something .. 3454 } 3455 ... 3456 </pre> 3457 <p>It would be much better, in this code, to redeclare fileLock as</p> 3458 <pre> 3459 private static final Object fileLock = new Object(); 3460 </pre> 3461 <p> 3462 The existing code might be OK, but it is confusing and a 3463 future refactoring, such as the "Remove Boxing" refactoring in IntelliJ, 3464 might replace this with the use of an interned Integer object shared 3465 throughout the JVM, leading to very confusing behavior and potential deadlock. 3466 </p> 3467 3468 3469 <h3><a name="DM_MONITOR_WAIT_ON_CONDITION">Dm: Monitor wait() called on Condition (DM_MONITOR_WAIT_ON_CONDITION)</a></h3> 3470 3471 3472 <p> 3473 This method calls <code>wait()</code> on a 3474 <code>java.util.concurrent.locks.Condition</code> object. 3475 Waiting for a <code>Condition</code> should be done using one of the <code>await()</code> 3476 methods defined by the <code>Condition</code> interface. 3477 </p> 3478 3479 3480 <h3><a name="DM_USELESS_THREAD">Dm: A thread was created using the default empty run method (DM_USELESS_THREAD)</a></h3> 3481 3482 3483 <p>This method creates a thread without specifying a run method either by deriving from the Thread class, or 3484 by passing a Runnable object. This thread, then, does nothing but waste time. 3485 </p> 3486 3487 3488 <h3><a name="ESync_EMPTY_SYNC">ESync: Empty synchronized block (ESync_EMPTY_SYNC)</a></h3> 3489 3490 3491 <p> The code contains an empty synchronized block:</p> 3492 <pre> 3493 synchronized() {} 3494 </pre> 3495 <p>Empty synchronized blocks are far more subtle and hard to use correctly 3496 than most people recognize, and empty synchronized blocks 3497 are almost never a better solution 3498 than less contrived solutions. 3499 </p> 3500 3501 3502 <h3><a name="IS2_INCONSISTENT_SYNC">IS: Inconsistent synchronization (IS2_INCONSISTENT_SYNC)</a></h3> 3503 3504 3505 <p> The fields of this class appear to be accessed inconsistently with respect 3506 to synchronization. This bug report indicates that the bug pattern detector 3507 judged that 3508 </p> 3509 <ul> 3510 <li> The class contains a mix of locked and unlocked accesses,</li> 3511 <li> The class is <b>not</b> annotated as javax.annotation.concurrent.NotThreadSafe,</li> 3512 <li> At least one locked access was performed by one of the class's own methods, and</li> 3513 <li> The number of unsynchronized field accesses (reads and writes) was no more than 3514 one third of all accesses, with writes being weighed twice as high as reads</li> 3515 </ul> 3516 3517 <p> A typical bug matching this bug pattern is forgetting to synchronize 3518 one of the methods in a class that is intended to be thread-safe.</p> 3519 3520 <p> You can select the nodes labeled "Unsynchronized access" to show the 3521 code locations where the detector believed that a field was accessed 3522 without synchronization.</p> 3523 3524 <p> Note that there are various sources of inaccuracy in this detector; 3525 for example, the detector cannot statically detect all situations in which 3526 a lock is held. Also, even when the detector is accurate in 3527 distinguishing locked vs. unlocked accesses, the code in question may still 3528 be correct.</p> 3529 3530 3531 3532 <h3><a name="IS_FIELD_NOT_GUARDED">IS: Field not guarded against concurrent access (IS_FIELD_NOT_GUARDED)</a></h3> 3533 3534 3535 <p> This field is annotated with net.jcip.annotations.GuardedBy or javax.annotation.concurrent.GuardedBy, 3536 but can be accessed in a way that seems to violate those annotations.</p> 3537 3538 3539 <h3><a name="JLM_JSR166_LOCK_MONITORENTER">JLM: Synchronization performed on Lock (JLM_JSR166_LOCK_MONITORENTER)</a></h3> 3540 3541 3542 <p> This method performs synchronization an object that implements 3543 java.util.concurrent.locks.Lock. Such an object is locked/unlocked 3544 using 3545 <code>acquire()</code>/<code>release()</code> rather 3546 than using the <code>synchronized (...)</code> construct. 3547 </p> 3548 3549 3550 <h3><a name="JLM_JSR166_UTILCONCURRENT_MONITORENTER">JLM: Synchronization performed on util.concurrent instance (JLM_JSR166_UTILCONCURRENT_MONITORENTER)</a></h3> 3551 3552 3553 <p> This method performs synchronization an object that is an instance of 3554 a class from the java.util.concurrent package (or its subclasses). Instances 3555 of these classes have their own concurrency control mechanisms that are orthogonal to 3556 the synchronization provided by the Java keyword <code>synchronized</code>. For example, 3557 synchronizing on an <code>AtomicBoolean</code> will not prevent other threads 3558 from modifying the <code>AtomicBoolean</code>.</p> 3559 <p>Such code may be correct, but should be carefully reviewed and documented, 3560 and may confuse people who have to maintain the code at a later date. 3561 </p> 3562 3563 3564 <h3><a name="JML_JSR166_CALLING_WAIT_RATHER_THAN_AWAIT">JLM: Using monitor style wait methods on util.concurrent abstraction (JML_JSR166_CALLING_WAIT_RATHER_THAN_AWAIT)</a></h3> 3565 3566 3567 <p> This method calls 3568 <code>wait()</code>, 3569 <code>notify()</code> or 3570 <code>notifyAll()()</code> 3571 on an object that also provides an 3572 <code>await()</code>, 3573 <code>signal()</code>, 3574 <code>signalAll()</code> method (such as util.concurrent Condition objects). 3575 This probably isn't what you want, and even if you do want it, you should consider changing 3576 your design, as other developers will find it exceptionally confusing. 3577 </p> 3578 3579 3580 <h3><a name="LI_LAZY_INIT_STATIC">LI: Incorrect lazy initialization of static field (LI_LAZY_INIT_STATIC)</a></h3> 3581 3582 3583 <p> This method contains an unsynchronized lazy initialization of a non-volatile static field. 3584 Because the compiler or processor may reorder instructions, 3585 threads are not guaranteed to see a completely initialized object, 3586 <em>if the method can be called by multiple threads</em>. 3587 You can make the field volatile to correct the problem. 3588 For more information, see the 3589 <a href="http://www.cs.umd.edu/~pugh/java/memoryModel/">Java Memory Model web site</a>. 3590 </p> 3591 3592 3593 <h3><a name="LI_LAZY_INIT_UPDATE_STATIC">LI: Incorrect lazy initialization and update of static field (LI_LAZY_INIT_UPDATE_STATIC)</a></h3> 3594 3595 3596 <p> This method contains an unsynchronized lazy initialization of a static field. 3597 After the field is set, the object stored into that location is further updated or accessed. 3598 The setting of the field is visible to other threads as soon as it is set. If the 3599 futher accesses in the method that set the field serve to initialize the object, then 3600 you have a <em>very serious</em> multithreading bug, unless something else prevents 3601 any other thread from accessing the stored object until it is fully initialized. 3602 </p> 3603 <p>Even if you feel confident that the method is never called by multiple 3604 threads, it might be better to not set the static field until the value 3605 you are setting it to is fully populated/initialized. 3606 3607 3608 <h3><a name="ML_SYNC_ON_FIELD_TO_GUARD_CHANGING_THAT_FIELD">ML: Synchronization on field in futile attempt to guard that field (ML_SYNC_ON_FIELD_TO_GUARD_CHANGING_THAT_FIELD)</a></h3> 3609 3610 3611 <p> This method synchronizes on a field in what appears to be an attempt 3612 to guard against simultaneous updates to that field. But guarding a field 3613 gets a lock on the referenced object, not on the field. This may not 3614 provide the mutual exclusion you need, and other threads might 3615 be obtaining locks on the referenced objects (for other purposes). An example 3616 of this pattern would be:</p> 3617 <pre> 3618 private Long myNtfSeqNbrCounter = new Long(0); 3619 private Long getNotificationSequenceNumber() { 3620 Long result = null; 3621 synchronized(myNtfSeqNbrCounter) { 3622 result = new Long(myNtfSeqNbrCounter.longValue() + 1); 3623 myNtfSeqNbrCounter = new Long(result.longValue()); 3624 } 3625 return result; 3626 } 3627 </pre> 3628 3629 3630 <h3><a name="ML_SYNC_ON_UPDATED_FIELD">ML: Method synchronizes on an updated field (ML_SYNC_ON_UPDATED_FIELD)</a></h3> 3631 3632 3633 <p> This method synchronizes on an object 3634 referenced from a mutable field. 3635 This is unlikely to have useful semantics, since different 3636 threads may be synchronizing on different objects.</p> 3637 3638 3639 <h3><a name="MSF_MUTABLE_SERVLET_FIELD">MSF: Mutable servlet field (MSF_MUTABLE_SERVLET_FIELD)</a></h3> 3640 3641 3642 <p>A web server generally only creates one instance of servlet or jsp class (i.e., treats 3643 the class as a Singleton), 3644 and will 3645 have multiple threads invoke methods on that instance to service multiple 3646 simultaneous requests. 3647 Thus, having a mutable instance field generally creates race conditions. 3648 3649 3650 <h3><a name="MWN_MISMATCHED_NOTIFY">MWN: Mismatched notify() (MWN_MISMATCHED_NOTIFY)</a></h3> 3651 3652 3653 <p> This method calls Object.notify() or Object.notifyAll() without obviously holding a lock 3654 on the object. Calling notify() or notifyAll() without a lock held will result in 3655 an <code>IllegalMonitorStateException</code> being thrown.</p> 3656 3657 3658 <h3><a name="MWN_MISMATCHED_WAIT">MWN: Mismatched wait() (MWN_MISMATCHED_WAIT)</a></h3> 3659 3660 3661 <p> This method calls Object.wait() without obviously holding a lock 3662 on the object. Calling wait() without a lock held will result in 3663 an <code>IllegalMonitorStateException</code> being thrown.</p> 3664 3665 3666 <h3><a name="NN_NAKED_NOTIFY">NN: Naked notify (NN_NAKED_NOTIFY)</a></h3> 3667 3668 3669 <p> A call to <code>notify()</code> or <code>notifyAll()</code> 3670 was made without any (apparent) accompanying 3671 modification to mutable object state. In general, calling a notify 3672 method on a monitor is done because some condition another thread is 3673 waiting for has become true. However, for the condition to be meaningful, 3674 it must involve a heap object that is visible to both threads.</p> 3675 3676 <p> This bug does not necessarily indicate an error, since the change to 3677 mutable object state may have taken place in a method which then called 3678 the method containing the notification.</p> 3679 3680 3681 <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> 3682 3683 3684 <p>Since the field is synchronized on, it seems not likely to be null. 3685 If it is null and then synchronized on a NullPointerException will be 3686 thrown and the check would be pointless. Better to synchronize on 3687 another field.</p> 3688 3689 3690 3691 <h3><a name="NO_NOTIFY_NOT_NOTIFYALL">No: Using notify() rather than notifyAll() (NO_NOTIFY_NOT_NOTIFYALL)</a></h3> 3692 3693 3694 <p> This method calls <code>notify()</code> rather than <code>notifyAll()</code>. 3695 Java monitors are often used for multiple conditions. Calling <code>notify()</code> 3696 only wakes up one thread, meaning that the thread woken up might not be the 3697 one waiting for the condition that the caller just satisfied.</p> 3698 3699 3700 <h3><a name="RS_READOBJECT_SYNC">RS: Class's readObject() method is synchronized (RS_READOBJECT_SYNC)</a></h3> 3701 3702 3703 <p> This serializable class defines a <code>readObject()</code> which is 3704 synchronized. By definition, an object created by deserialization 3705 is only reachable by one thread, and thus there is no need for 3706 <code>readObject()</code> to be synchronized. If the <code>readObject()</code> 3707 method itself is causing the object to become visible to another thread, 3708 that is an example of very dubious coding style.</p> 3709 3710 3711 <h3><a name="RV_RETURN_VALUE_OF_PUTIFABSENT_IGNORED">RV: Return value of putIfAbsent ignored, value passed to putIfAbsent reused (RV_RETURN_VALUE_OF_PUTIFABSENT_IGNORED)</a></h3> 3712 3713 3714 The <code>putIfAbsent</code> method is typically used to ensure that a 3715 single value is associated with a given key (the first value for which put 3716 if absent succeeds). 3717 If you ignore the return value and retain a reference to the value passed in, 3718 you run the risk of retaining a value that is not the one that is associated with the key in the map. 3719 If it matters which one you use and you use the one that isn't stored in the map, 3720 your program will behave incorrectly. 3721 3722 3723 <h3><a name="RU_INVOKE_RUN">Ru: Invokes run on a thread (did you mean to start it instead?) (RU_INVOKE_RUN)</a></h3> 3724 3725 3726 <p> This method explicitly invokes <code>run()</code> on an object. 3727 In general, classes implement the <code>Runnable</code> interface because 3728 they are going to have their <code>run()</code> method invoked in a new thread, 3729 in which case <code>Thread.start()</code> is the right method to call.</p> 3730 3731 3732 <h3><a name="SC_START_IN_CTOR">SC: Constructor invokes Thread.start() (SC_START_IN_CTOR)</a></h3> 3733 3734 3735 <p> The constructor starts a thread. This is likely to be wrong if 3736 the class is ever extended/subclassed, since the thread will be started 3737 before the subclass constructor is started.</p> 3738 3739 3740 <h3><a name="SP_SPIN_ON_FIELD">SP: Method spins on field (SP_SPIN_ON_FIELD)</a></h3> 3741 3742 3743 <p> This method spins in a loop which reads a field. The compiler 3744 may legally hoist the read out of the loop, turning the code into an 3745 infinite loop. The class should be changed so it uses proper 3746 synchronization (including wait and notify calls).</p> 3747 3748 3749 <h3><a name="STCAL_INVOKE_ON_STATIC_CALENDAR_INSTANCE">STCAL: Call to static Calendar (STCAL_INVOKE_ON_STATIC_CALENDAR_INSTANCE)</a></h3> 3750 3751 3752 <p>Even though the JavaDoc does not contain a hint about it, Calendars are inherently unsafe for multihtreaded use. 3753 The detector has found a call to an instance of Calendar that has been obtained via a static 3754 field. This looks suspicous.</p> 3755 <p>For more information on this see <a href="http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6231579">Sun Bug #6231579</a> 3756 and <a href="http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6178997">Sun Bug #6178997</a>.</p> 3757 3758 3759 <h3><a name="STCAL_INVOKE_ON_STATIC_DATE_FORMAT_INSTANCE">STCAL: Call to static DateFormat (STCAL_INVOKE_ON_STATIC_DATE_FORMAT_INSTANCE)</a></h3> 3760 3761 3762 <p>As the JavaDoc states, DateFormats are inherently unsafe for multithreaded use. 3763 The detector has found a call to an instance of DateFormat that has been obtained via a static 3764 field. This looks suspicous.</p> 3765 <p>For more information on this see <a href="http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6231579">Sun Bug #6231579</a> 3766 and <a href="http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6178997">Sun Bug #6178997</a>.</p> 3767 3768 3769 <h3><a name="STCAL_STATIC_CALENDAR_INSTANCE">STCAL: Static Calendar field (STCAL_STATIC_CALENDAR_INSTANCE)</a></h3> 3770 3771 3772 <p>Even though the JavaDoc does not contain a hint about it, Calendars are inherently unsafe for multihtreaded use. 3773 Sharing a single instance across thread boundaries without proper synchronization will result in erratic behavior of the 3774 application. Under 1.4 problems seem to surface less often than under Java 5 where you will probably see 3775 random ArrayIndexOutOfBoundsExceptions or IndexOutOfBoundsExceptions in sun.util.calendar.BaseCalendar.getCalendarDateFromFixedDate().</p> 3776 <p>You may also experience serialization problems.</p> 3777 <p>Using an instance field is recommended.</p> 3778 <p>For more information on this see <a href="http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6231579">Sun Bug #6231579</a> 3779 and <a href="http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6178997">Sun Bug #6178997</a>.</p> 3780 3781 3782 <h3><a name="STCAL_STATIC_SIMPLE_DATE_FORMAT_INSTANCE">STCAL: Static DateFormat (STCAL_STATIC_SIMPLE_DATE_FORMAT_INSTANCE)</a></h3> 3783 3784 3785 <p>As the JavaDoc states, DateFormats are inherently unsafe for multithreaded use. 3786 Sharing a single instance across thread boundaries without proper synchronization will result in erratic behavior of the 3787 application.</p> 3788 <p>You may also experience serialization problems.</p> 3789 <p>Using an instance field is recommended.</p> 3790 <p>For more information on this see <a href="http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6231579">Sun Bug #6231579</a> 3791 and <a href="http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6178997">Sun Bug #6178997</a>.</p> 3792 3793 3794 <h3><a name="SWL_SLEEP_WITH_LOCK_HELD">SWL: Method calls Thread.sleep() with a lock held (SWL_SLEEP_WITH_LOCK_HELD)</a></h3> 3795 3796 3797 <p> 3798 This method calls Thread.sleep() with a lock held. This may result 3799 in very poor performance and scalability, or a deadlock, since other threads may 3800 be waiting to acquire the lock. It is a much better idea to call 3801 wait() on the lock, which releases the lock and allows other threads 3802 to run. 3803 </p> 3804 3805 3806 <h3><a name="TLW_TWO_LOCK_WAIT">TLW: Wait with two locks held (TLW_TWO_LOCK_WAIT)</a></h3> 3807 3808 3809 <p> Waiting on a monitor while two locks are held may cause 3810 deadlock. 3811 3812 Performing a wait only releases the lock on the object 3813 being waited on, not any other locks. 3814 3815 This not necessarily a bug, but is worth examining 3816 closely.</p> 3817 3818 3819 <h3><a name="UG_SYNC_SET_UNSYNC_GET">UG: Unsynchronized get method, synchronized set method (UG_SYNC_SET_UNSYNC_GET)</a></h3> 3820 3821 3822 <p> This class contains similarly-named get and set 3823 methods where the set method is synchronized and the get method is not. 3824 This may result in incorrect behavior at runtime, as callers of the get 3825 method will not necessarily see a consistent state for the object. 3826 The get method should be made synchronized.</p> 3827 3828 3829 <h3><a name="UL_UNRELEASED_LOCK">UL: Method does not release lock on all paths (UL_UNRELEASED_LOCK)</a></h3> 3830 3831 3832 <p> This method acquires a JSR-166 (<code>java.util.concurrent</code>) lock, 3833 but does not release it on all paths out of the method. In general, the correct idiom 3834 for using a JSR-166 lock is: 3835 </p> 3836 <pre> 3837 Lock l = ...; 3838 l.lock(); 3839 try { 3840 // do something 3841 } finally { 3842 l.unlock(); 3843 } 3844 </pre> 3845 3846 3847 <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> 3848 3849 3850 <p> This method acquires a JSR-166 (<code>java.util.concurrent</code>) lock, 3851 but does not release it on all exception paths out of the method. In general, the correct idiom 3852 for using a JSR-166 lock is: 3853 </p> 3854 <pre> 3855 Lock l = ...; 3856 l.lock(); 3857 try { 3858 // do something 3859 } finally { 3860 l.unlock(); 3861 } 3862 </pre> 3863 3864 3865 <h3><a name="UW_UNCOND_WAIT">UW: Unconditional wait (UW_UNCOND_WAIT)</a></h3> 3866 3867 3868 <p> This method contains a call to <code>java.lang.Object.wait()</code> which 3869 is not guarded by conditional control flow. The code should 3870 verify that condition it intends to wait for is not already satisfied 3871 before calling wait; any previous notifications will be ignored. 3872 </p> 3873 3874 3875 <h3><a name="VO_VOLATILE_INCREMENT">VO: An increment to a volatile field isn't atomic (VO_VOLATILE_INCREMENT)</a></h3> 3876 3877 3878 <p>This code increments a volatile field. Increments of volatile fields aren't 3879 atomic. If more than one thread is incrementing the field at the same time, 3880 increments could be lost. 3881 </p> 3882 3883 3884 <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> 3885 3886 3887 <p>This declares a volatile reference to an array, which might not be what 3888 you want. With a volatile reference to an array, reads and writes of 3889 the reference to the array are treated as volatile, but the array elements 3890 are non-volatile. To get volatile array elements, you will need to use 3891 one of the atomic array classes in java.util.concurrent (provided 3892 in Java 5.0).</p> 3893 3894 3895 <h3><a name="WL_USING_GETCLASS_RATHER_THAN_CLASS_LITERAL">WL: Synchronization on getClass rather than class literal (WL_USING_GETCLASS_RATHER_THAN_CLASS_LITERAL)</a></h3> 3896 3897 3898 <p> 3899 This instance method synchronizes on <code>this.getClass()</code>. If this class is subclassed, 3900 subclasses will synchronize on the class object for the subclass, which isn't likely what was intended. 3901 For example, consider this code from java.awt.Label:</p> 3902 <pre> 3903 private static final String base = "label"; 3904 private static int nameCounter = 0; 3905 String constructComponentName() { 3906 synchronized (getClass()) { 3907 return base + nameCounter++; 3908 } 3909 } 3910 </pre> 3911 <p>Subclasses of <code>Label</code> won't synchronize on the same subclass, giving rise to a datarace. 3912 Instead, this code should be synchronizing on <code>Label.class</code></p> 3913 <pre> 3914 private static final String base = "label"; 3915 private static int nameCounter = 0; 3916 String constructComponentName() { 3917 synchronized (Label.class) { 3918 return base + nameCounter++; 3919 } 3920 } 3921 </pre> 3922 <p>Bug pattern contributed by Jason Mehrens</p> 3923 3924 3925 <h3><a name="WS_WRITEOBJECT_SYNC">WS: Class's writeObject() method is synchronized but nothing else is (WS_WRITEOBJECT_SYNC)</a></h3> 3926 3927 3928 <p> This class has a <code>writeObject()</code> method which is synchronized; 3929 however, no other method of the class is synchronized.</p> 3930 3931 3932 <h3><a name="WA_AWAIT_NOT_IN_LOOP">Wa: Condition.await() not in loop (WA_AWAIT_NOT_IN_LOOP)</a></h3> 3933 3934 3935 <p> This method contains a call to <code>java.util.concurrent.await()</code> 3936 (or variants) 3937 which is not in a loop. If the object is used for multiple conditions, 3938 the condition the caller intended to wait for might not be the one 3939 that actually occurred.</p> 3940 3941 3942 <h3><a name="WA_NOT_IN_LOOP">Wa: Wait not in loop (WA_NOT_IN_LOOP)</a></h3> 3943 3944 3945 <p> This method contains a call to <code>java.lang.Object.wait()</code> 3946 which is not in a loop. If the monitor is used for multiple conditions, 3947 the condition the caller intended to wait for might not be the one 3948 that actually occurred.</p> 3949 3950 3951 <h3><a name="BX_BOXING_IMMEDIATELY_UNBOXED">Bx: Primitive value is boxed and then immediately unboxed (BX_BOXING_IMMEDIATELY_UNBOXED)</a></h3> 3952 3953 3954 <p>A primitive is boxed, and then immediately unboxed. This probably is due to a manual 3955 boxing in a place where an unboxed value is required, thus forcing the compiler 3956 to immediately undo the work of the boxing. 3957 </p> 3958 3959 3960 <h3><a name="BX_BOXING_IMMEDIATELY_UNBOXED_TO_PERFORM_COERCION">Bx: Primitive value is boxed then unboxed to perform primitive coercion (BX_BOXING_IMMEDIATELY_UNBOXED_TO_PERFORM_COERCION)</a></h3> 3961 3962 3963 <p>A primitive boxed value constructed and then immediately converted into a different primitive type 3964 (e.g., <code>new Double(d).intValue()</code>). Just perform direct primitive coercion (e.g., <code>(int) d</code>).</p> 3965 3966 3967 <h3><a name="BX_UNBOXING_IMMEDIATELY_REBOXED">Bx: Boxed value is unboxed and then immediately reboxed (BX_UNBOXING_IMMEDIATELY_REBOXED)</a></h3> 3968 3969 3970 <p>A boxed value is unboxed and then immediately reboxed. 3971 </p> 3972 3973 3974 <h3><a name="DM_BOXED_PRIMITIVE_FOR_PARSING">Bx: Boxing/unboxing to parse a primitive (DM_BOXED_PRIMITIVE_FOR_PARSING)</a></h3> 3975 3976 3977 <p>A boxed primitive is created from a String, just to extract the unboxed primitive value. 3978 It is more efficient to just call the static parseXXX method.</p> 3979 3980 3981 <h3><a name="DM_BOXED_PRIMITIVE_TOSTRING">Bx: Method allocates a boxed primitive just to call toString (DM_BOXED_PRIMITIVE_TOSTRING)</a></h3> 3982 3983 3984 <p>A boxed primitive is allocated just to call toString(). It is more effective to just use the static 3985 form of toString which takes the primitive value. So,</p> 3986 <table> 3987 <tr><th>Replace...</th><th>With this...</th></tr> 3988 <tr><td>new Integer(1).toString()</td><td>Integer.toString(1)</td></tr> 3989 <tr><td>new Long(1).toString()</td><td>Long.toString(1)</td></tr> 3990 <tr><td>new Float(1.0).toString()</td><td>Float.toString(1.0)</td></tr> 3991 <tr><td>new Double(1.0).toString()</td><td>Double.toString(1.0)</td></tr> 3992 <tr><td>new Byte(1).toString()</td><td>Byte.toString(1)</td></tr> 3993 <tr><td>new Short(1).toString()</td><td>Short.toString(1)</td></tr> 3994 <tr><td>new Boolean(true).toString()</td><td>Boolean.toString(true)</td></tr> 3995 </table> 3996 3997 3998 <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> 3999 4000 4001 <p> 4002 Using <code>new Double(double)</code> is guaranteed to always result in a new object whereas 4003 <code>Double.valueOf(double)</code> allows caching of values to be done by the compiler, class library, or JVM. 4004 Using of cached values avoids object allocation and the code will be faster. 4005 </p> 4006 <p> 4007 Unless the class must be compatible with JVMs predating Java 1.5, 4008 use either autoboxing or the <code>valueOf()</code> method when creating instances of <code>Double</code> and <code>Float</code>. 4009 </p> 4010 4011 4012 <h3><a name="DM_NUMBER_CTOR">Bx: Method invokes inefficient Number constructor; use static valueOf instead (DM_NUMBER_CTOR)</a></h3> 4013 4014 4015 <p> 4016 Using <code>new Integer(int)</code> is guaranteed to always result in a new object whereas 4017 <code>Integer.valueOf(int)</code> allows caching of values to be done by the compiler, class library, or JVM. 4018 Using of cached values avoids object allocation and the code will be faster. 4019 </p> 4020 <p> 4021 Values between -128 and 127 are guaranteed to have corresponding cached instances 4022 and using <code>valueOf</code> is approximately 3.5 times faster than using constructor. 4023 For values outside the constant range the performance of both styles is the same. 4024 </p> 4025 <p> 4026 Unless the class must be compatible with JVMs predating Java 1.5, 4027 use either autoboxing or the <code>valueOf()</code> method when creating instances of 4028 <code>Long</code>, <code>Integer</code>, <code>Short</code>, <code>Character</code>, and <code>Byte</code>. 4029 </p> 4030 4031 4032 <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> 4033 4034 4035 <p> The equals and hashCode 4036 method of URL perform domain name resolution, this can result in a big performance hit. 4037 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. 4038 Consider using <code>java.net.URI</code> instead. 4039 </p> 4040 4041 4042 <h3><a name="DMI_COLLECTION_OF_URLS">Dm: Maps and sets of URLs can be performance hogs (DMI_COLLECTION_OF_URLS)</a></h3> 4043 4044 4045 <p> This method or field is or uses a Map or Set of URLs. Since both the equals and hashCode 4046 method of URL perform domain name resolution, this can result in a big performance hit. 4047 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. 4048 Consider using <code>java.net.URI</code> instead. 4049 </p> 4050 4051 4052 <h3><a name="DM_BOOLEAN_CTOR">Dm: Method invokes inefficient Boolean constructor; use Boolean.valueOf(...) instead (DM_BOOLEAN_CTOR)</a></h3> 4053 4054 4055 <p> Creating new instances of <code>java.lang.Boolean</code> wastes 4056 memory, since <code>Boolean</code> objects are immutable and there are 4057 only two useful values of this type. Use the <code>Boolean.valueOf()</code> 4058 method (or Java 1.5 autoboxing) to create <code>Boolean</code> objects instead.</p> 4059 4060 4061 <h3><a name="DM_GC">Dm: Explicit garbage collection; extremely dubious except in benchmarking code (DM_GC)</a></h3> 4062 4063 4064 <p> Code explicitly invokes garbage collection. 4065 Except for specific use in benchmarking, this is very dubious.</p> 4066 <p>In the past, situations where people have explicitly invoked 4067 the garbage collector in routines such as close or finalize methods 4068 has led to huge performance black holes. Garbage collection 4069 can be expensive. Any situation that forces hundreds or thousands 4070 of garbage collections will bring the machine to a crawl.</p> 4071 4072 4073 <h3><a name="DM_NEW_FOR_GETCLASS">Dm: Method allocates an object, only to get the class object (DM_NEW_FOR_GETCLASS)</a></h3> 4074 4075 4076 <p>This method allocates an object just to call getClass() on it, in order to 4077 retrieve the Class object for it. It is simpler to just access the .class property of the class.</p> 4078 4079 4080 <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> 4081 4082 4083 <p>If <code>r</code> is a <code>java.util.Random</code>, you can generate a random number from <code>0</code> to <code>n-1</code> 4084 using <code>r.nextInt(n)</code>, rather than using <code>(int)(r.nextDouble() * n)</code>. 4085 </p> 4086 <p>The argument to nextInt must be positive. If, for example, you want to generate a random 4087 value from -99 to 0, use <code>-r.nextInt(100)</code>. 4088 </p> 4089 4090 4091 <h3><a name="DM_STRING_CTOR">Dm: Method invokes inefficient new String(String) constructor (DM_STRING_CTOR)</a></h3> 4092 4093 4094 <p> Using the <code>java.lang.String(String)</code> constructor wastes memory 4095 because the object so constructed will be functionally indistinguishable 4096 from the <code>String</code> passed as a parameter. Just use the 4097 argument <code>String</code> directly.</p> 4098 4099 4100 <h3><a name="DM_STRING_TOSTRING">Dm: Method invokes toString() method on a String (DM_STRING_TOSTRING)</a></h3> 4101 4102 4103 <p> Calling <code>String.toString()</code> is just a redundant operation. 4104 Just use the String.</p> 4105 4106 4107 <h3><a name="DM_STRING_VOID_CTOR">Dm: Method invokes inefficient new String() constructor (DM_STRING_VOID_CTOR)</a></h3> 4108 4109 4110 <p> Creating a new <code>java.lang.String</code> object using the 4111 no-argument constructor wastes memory because the object so created will 4112 be functionally indistinguishable from the empty string constant 4113 <code>""</code>. Java guarantees that identical string constants 4114 will be represented by the same <code>String</code> object. Therefore, 4115 you should just use the empty string constant directly.</p> 4116 4117 4118 <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> 4119 4120 4121 <p> 4122 A large String constant is duplicated across multiple class files. 4123 This is likely because a final field is initialized to a String constant, and the Java language 4124 mandates that all references to a final field from other classes be inlined into 4125 that classfile. See <a href="http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6447475">JDK bug 6447475</a> 4126 for a description of an occurrence of this bug in the JDK and how resolving it reduced 4127 the size of the JDK by 1 megabyte. 4128 </p> 4129 4130 4131 <h3><a name="ITA_INEFFICIENT_TO_ARRAY">ITA: Method uses toArray() with zero-length array argument (ITA_INEFFICIENT_TO_ARRAY)</a></h3> 4132 4133 4134 <p> This method uses the toArray() method of a collection derived class, and passes 4135 in a zero-length prototype array argument. It is more efficient to use 4136 <code>myCollection.toArray(new Foo[myCollection.size()])</code> 4137 If the array passed in is big enough to store all of the 4138 elements of the collection, then it is populated and returned 4139 directly. This avoids the need to create a second array 4140 (by reflection) to return as the result.</p> 4141 4142 4143 <h3><a name="SBSC_USE_STRINGBUFFER_CONCATENATION">SBSC: Method concatenates strings using + in a loop (SBSC_USE_STRINGBUFFER_CONCATENATION)</a></h3> 4144 4145 4146 <p> The method seems to be building a String using concatenation in a loop. 4147 In each iteration, the String is converted to a StringBuffer/StringBuilder, 4148 appended to, and converted back to a String. 4149 This can lead to a cost quadratic in the number of iterations, 4150 as the growing string is recopied in each iteration. </p> 4151 4152 <p>Better performance can be obtained by using 4153 a StringBuffer (or StringBuilder in Java 1.5) explicitly.</p> 4154 4155 <p> For example:</p> 4156 <pre> 4157 // This is bad 4158 String s = ""; 4159 for (int i = 0; i < field.length; ++i) { 4160 s = s + field[i]; 4161 } 4162 4163 // This is better 4164 StringBuffer buf = new StringBuffer(); 4165 for (int i = 0; i < field.length; ++i) { 4166 buf.append(field[i]); 4167 } 4168 String s = buf.toString(); 4169 </pre> 4170 4171 4172 <h3><a name="SIC_INNER_SHOULD_BE_STATIC">SIC: Should be a static inner class (SIC_INNER_SHOULD_BE_STATIC)</a></h3> 4173 4174 4175 <p> This class is an inner class, but does not use its embedded reference 4176 to the object which created it. This reference makes the instances 4177 of the class larger, and may keep the reference to the creator object 4178 alive longer than necessary. If possible, the class should be 4179 made static. 4180 </p> 4181 4182 4183 <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> 4184 4185 4186 <p> This class is an inner class, but does not use its embedded reference 4187 to the object which created it. This reference makes the instances 4188 of the class larger, and may keep the reference to the creator object 4189 alive longer than necessary. If possible, the class should be 4190 made into a <em>static</em> inner class. Since anonymous inner 4191 classes cannot be marked as static, doing this will require refactoring 4192 the inner class so that it is a named inner class.</p> 4193 4194 4195 <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> 4196 4197 4198 <p> This class is an inner class, but does not use its embedded reference 4199 to the object which created it except during construction of the 4200 inner object. This reference makes the instances 4201 of the class larger, and may keep the reference to the creator object 4202 alive longer than necessary. If possible, the class should be 4203 made into a <em>static</em> inner class. Since the reference to the 4204 outer object is required during construction of the inner instance, 4205 the inner class will need to be refactored so as to 4206 pass a reference to the outer instance to the constructor 4207 for the inner class.</p> 4208 4209 4210 <h3><a name="SS_SHOULD_BE_STATIC">SS: Unread field: should this field be static? (SS_SHOULD_BE_STATIC)</a></h3> 4211 4212 4213 <p> This class contains an instance final field that 4214 is initialized to a compile-time static value. 4215 Consider making the field static.</p> 4216 4217 4218 <h3><a name="UM_UNNECESSARY_MATH">UM: Method calls static Math class method on a constant value (UM_UNNECESSARY_MATH)</a></h3> 4219 4220 4221 <p> This method uses a static method from java.lang.Math on a constant value. This method's 4222 result in this case, can be determined statically, and is faster and sometimes more accurate to 4223 just use the constant. Methods detected are: 4224 </p> 4225 <table> 4226 <tr> 4227 <th>Method</th> <th>Parameter</th> 4228 </tr> 4229 <tr> 4230 <td>abs</td> <td>-any-</td> 4231 </tr> 4232 <tr> 4233 <td>acos</td> <td>0.0 or 1.0</td> 4234 </tr> 4235 <tr> 4236 <td>asin</td> <td>0.0 or 1.0</td> 4237 </tr> 4238 <tr> 4239 <td>atan</td> <td>0.0 or 1.0</td> 4240 </tr> 4241 <tr> 4242 <td>atan2</td> <td>0.0</td> 4243 </tr> 4244 <tr> 4245 <td>cbrt</td> <td>0.0 or 1.0</td> 4246 </tr> 4247 <tr> 4248 <td>ceil</td> <td>-any-</td> 4249 </tr> 4250 <tr> 4251 <td>cos</td> <td>0.0</td> 4252 </tr> 4253 <tr> 4254 <td>cosh</td> <td>0.0</td> 4255 </tr> 4256 <tr> 4257 <td>exp</td> <td>0.0 or 1.0</td> 4258 </tr> 4259 <tr> 4260 <td>expm1</td> <td>0.0</td> 4261 </tr> 4262 <tr> 4263 <td>floor</td> <td>-any-</td> 4264 </tr> 4265 <tr> 4266 <td>log</td> <td>0.0 or 1.0</td> 4267 </tr> 4268 <tr> 4269 <td>log10</td> <td>0.0 or 1.0</td> 4270 </tr> 4271 <tr> 4272 <td>rint</td> <td>-any-</td> 4273 </tr> 4274 <tr> 4275 <td>round</td> <td>-any-</td> 4276 </tr> 4277 <tr> 4278 <td>sin</td> <td>0.0</td> 4279 </tr> 4280 <tr> 4281 <td>sinh</td> <td>0.0</td> 4282 </tr> 4283 <tr> 4284 <td>sqrt</td> <td>0.0 or 1.0</td> 4285 </tr> 4286 <tr> 4287 <td>tan</td> <td>0.0</td> 4288 </tr> 4289 <tr> 4290 <td>tanh</td> <td>0.0</td> 4291 </tr> 4292 <tr> 4293 <td>toDegrees</td> <td>0.0 or 1.0</td> 4294 </tr> 4295 <tr> 4296 <td>toRadians</td> <td>0.0</td> 4297 </tr> 4298 </table> 4299 4300 4301 <h3><a name="UPM_UNCALLED_PRIVATE_METHOD">UPM: Private method is never called (UPM_UNCALLED_PRIVATE_METHOD)</a></h3> 4302 4303 4304 <p> This private method is never called. Although it is 4305 possible that the method will be invoked through reflection, 4306 it is more likely that the method is never used, and should be 4307 removed. 4308 </p> 4309 4310 4311 <h3><a name="URF_UNREAD_FIELD">UrF: Unread field (URF_UNREAD_FIELD)</a></h3> 4312 4313 4314 <p> This field is never read. Consider removing it from the class.</p> 4315 4316 4317 <h3><a name="UUF_UNUSED_FIELD">UuF: Unused field (UUF_UNUSED_FIELD)</a></h3> 4318 4319 4320 <p> This field is never used. Consider removing it from the class.</p> 4321 4322 4323 <h3><a name="WMI_WRONG_MAP_ITERATOR">WMI: Inefficient use of keySet iterator instead of entrySet iterator (WMI_WRONG_MAP_ITERATOR)</a></h3> 4324 4325 4326 <p> This method accesses the value of a Map entry, using a key that was retrieved from 4327 a keySet iterator. It is more efficient to use an iterator on the entrySet of the map, to avoid the 4328 Map.get(key) lookup.</p> 4329 4330 4331 <h3><a name="DMI_CONSTANT_DB_PASSWORD">Dm: Hardcoded constant database password (DMI_CONSTANT_DB_PASSWORD)</a></h3> 4332 4333 4334 <p>This code creates a database connect using a hardcoded, constant password. Anyone with access to either the source code or the compiled code can 4335 easily learn the password. 4336 </p> 4337 4338 4339 4340 <h3><a name="DMI_EMPTY_DB_PASSWORD">Dm: Empty database password (DMI_EMPTY_DB_PASSWORD)</a></h3> 4341 4342 4343 <p>This code creates a database connect using a blank or empty password. This indicates that the database is not protected by a password. 4344 </p> 4345 4346 4347 4348 <h3><a name="HRS_REQUEST_PARAMETER_TO_COOKIE">HRS: HTTP cookie formed from untrusted input (HRS_REQUEST_PARAMETER_TO_COOKIE)</a></h3> 4349 4350 4351 <p>This code constructs an HTTP Cookie using an untrusted HTTP parameter. If this cookie is added to an HTTP response, it will allow a HTTP response splitting 4352 vulnerability. See <a href="http://en.wikipedia.org/wiki/HTTP_response_splitting">http://en.wikipedia.org/wiki/HTTP_response_splitting</a> 4353 for more information.</p> 4354 <p>FindBugs looks only for the most blatant, obvious cases of HTTP response splitting. 4355 If FindBugs found <em>any</em>, you <em>almost certainly</em> have more 4356 vulnerabilities that FindBugs doesn't report. If you are concerned about HTTP response splitting, you should seriously 4357 consider using a commercial static analysis or pen-testing tool. 4358 </p> 4359 4360 4361 4362 <h3><a name="HRS_REQUEST_PARAMETER_TO_HTTP_HEADER">HRS: HTTP Response splitting vulnerability (HRS_REQUEST_PARAMETER_TO_HTTP_HEADER)</a></h3> 4363 4364 4365 <p>This code directly writes an HTTP parameter to an HTTP header, which allows for a HTTP response splitting 4366 vulnerability. See <a href="http://en.wikipedia.org/wiki/HTTP_response_splitting">http://en.wikipedia.org/wiki/HTTP_response_splitting</a> 4367 for more information.</p> 4368 <p>FindBugs looks only for the most blatant, obvious cases of HTTP response splitting. 4369 If FindBugs found <em>any</em>, you <em>almost certainly</em> have more 4370 vulnerabilities that FindBugs doesn't report. If you are concerned about HTTP response splitting, you should seriously 4371 consider using a commercial static analysis or pen-testing tool. 4372 </p> 4373 4374 4375 4376 <h3><a name="PT_ABSOLUTE_PATH_TRAVERSAL">PT: Absolute path traversal in servlet (PT_ABSOLUTE_PATH_TRAVERSAL)</a></h3> 4377 4378 4379 <p>The software uses an HTTP request parameter to construct a pathname that should be within a restricted directory, 4380 but it does not properly neutralize absolute path sequences such as "/abs/path" that can resolve to a location that is outside of that directory. 4381 4382 See <a href="http://cwe.mitre.org/data/definitions/36.html">http://cwe.mitre.org/data/definitions/36.html</a> 4383 for more information.</p> 4384 <p>FindBugs looks only for the most blatant, obvious cases of absolute path traversal. 4385 If FindBugs found <em>any</em>, you <em>almost certainly</em> have more 4386 vulnerabilities that FindBugs doesn't report. If you are concerned about absolute path traversal, you should seriously 4387 consider using a commercial static analysis or pen-testing tool. 4388 </p> 4389 4390 4391 4392 <h3><a name="PT_RELATIVE_PATH_TRAVERSAL">PT: Relative path traversal in servlet (PT_RELATIVE_PATH_TRAVERSAL)</a></h3> 4393 4394 4395 <p>The software uses an HTTP request parameter to construct a pathname that should be within a restricted directory, but it does not properly neutralize sequences such as ".." that can resolve to a location that is outside of that directory. 4396 4397 See <a href="http://cwe.mitre.org/data/definitions/23.html">http://cwe.mitre.org/data/definitions/23.html</a> 4398 for more information.</p> 4399 <p>FindBugs looks only for the most blatant, obvious cases of relative path traversal. 4400 If FindBugs found <em>any</em>, you <em>almost certainly</em> have more 4401 vulnerabilities that FindBugs doesn't report. If you are concerned about relative path traversal, you should seriously 4402 consider using a commercial static analysis or pen-testing tool. 4403 </p> 4404 4405 4406 4407 <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> 4408 4409 4410 <p>The method invokes the execute method on an SQL statement with a String that seems 4411 to be dynamically generated. Consider using 4412 a prepared statement instead. It is more efficient and less vulnerable to 4413 SQL injection attacks. 4414 </p> 4415 4416 4417 <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> 4418 4419 4420 <p>The code creates an SQL prepared statement from a nonconstant String. 4421 If unchecked, tainted data from a user is used in building this String, SQL injection could 4422 be used to make the prepared statement do something unexpected and undesirable. 4423 </p> 4424 4425 4426 <h3><a name="XSS_REQUEST_PARAMETER_TO_JSP_WRITER">XSS: JSP reflected cross site scripting vulnerability (XSS_REQUEST_PARAMETER_TO_JSP_WRITER)</a></h3> 4427 4428 4429 <p>This code directly writes an HTTP parameter to JSP output, which allows for a cross site scripting 4430 vulnerability. See <a href="http://en.wikipedia.org/wiki/Cross-site_scripting">http://en.wikipedia.org/wiki/Cross-site_scripting</a> 4431 for more information.</p> 4432 <p>FindBugs looks only for the most blatant, obvious cases of cross site scripting. 4433 If FindBugs found <em>any</em>, you <em>almost certainly</em> have more cross site scripting 4434 vulnerabilities that FindBugs doesn't report. If you are concerned about cross site scripting, you should seriously 4435 consider using a commercial static analysis or pen-testing tool. 4436 </p> 4437 4438 4439 <h3><a name="XSS_REQUEST_PARAMETER_TO_SEND_ERROR">XSS: Servlet reflected cross site scripting vulnerability in error page (XSS_REQUEST_PARAMETER_TO_SEND_ERROR)</a></h3> 4440 4441 4442 <p>This code directly writes an HTTP parameter to a Server error page (using HttpServletResponse.sendError). Echoing this untrusted input allows 4443 for a reflected cross site scripting 4444 vulnerability. See <a href="http://en.wikipedia.org/wiki/Cross-site_scripting">http://en.wikipedia.org/wiki/Cross-site_scripting</a> 4445 for more information.</p> 4446 <p>FindBugs looks only for the most blatant, obvious cases of cross site scripting. 4447 If FindBugs found <em>any</em>, you <em>almost certainly</em> have more cross site scripting 4448 vulnerabilities that FindBugs doesn't report. If you are concerned about cross site scripting, you should seriously 4449 consider using a commercial static analysis or pen-testing tool. 4450 </p> 4451 4452 4453 4454 <h3><a name="XSS_REQUEST_PARAMETER_TO_SERVLET_WRITER">XSS: Servlet reflected cross site scripting vulnerability (XSS_REQUEST_PARAMETER_TO_SERVLET_WRITER)</a></h3> 4455 4456 4457 <p>This code directly writes an HTTP parameter to Servlet output, which allows for a reflected cross site scripting 4458 vulnerability. See <a href="http://en.wikipedia.org/wiki/Cross-site_scripting">http://en.wikipedia.org/wiki/Cross-site_scripting</a> 4459 for more information.</p> 4460 <p>FindBugs looks only for the most blatant, obvious cases of cross site scripting. 4461 If FindBugs found <em>any</em>, you <em>almost certainly</em> have more cross site scripting 4462 vulnerabilities that FindBugs doesn't report. If you are concerned about cross site scripting, you should seriously 4463 consider using a commercial static analysis or pen-testing tool. 4464 </p> 4465 4466 4467 4468 <h3><a name="BC_BAD_CAST_TO_ABSTRACT_COLLECTION">BC: Questionable cast to abstract collection (BC_BAD_CAST_TO_ABSTRACT_COLLECTION)</a></h3> 4469 4470 4471 <p> 4472 This code casts a Collection to an abstract collection 4473 (such as <code>List</code>, <code>Set</code>, or <code>Map</code>). 4474 Ensure that you are guaranteed that the object is of the type 4475 you are casting to. If all you need is to be able 4476 to iterate through a collection, you don't need to cast it to a Set or List. 4477 </p> 4478 4479 4480 <h3><a name="BC_BAD_CAST_TO_CONCRETE_COLLECTION">BC: Questionable cast to concrete collection (BC_BAD_CAST_TO_CONCRETE_COLLECTION)</a></h3> 4481 4482 4483 <p> 4484 This code casts an abstract collection (such as a Collection, List, or Set) 4485 to a specific concrete implementation (such as an ArrayList or HashSet). 4486 This might not be correct, and it may make your code fragile, since 4487 it makes it harder to switch to other concrete implementations at a future 4488 point. Unless you have a particular reason to do so, just use the abstract 4489 collection class. 4490 </p> 4491 4492 4493 <h3><a name="BC_UNCONFIRMED_CAST">BC: Unchecked/unconfirmed cast (BC_UNCONFIRMED_CAST)</a></h3> 4494 4495 4496 <p> 4497 This cast is unchecked, and not all instances of the type casted from can be cast to 4498 the type it is being cast to. Check that your program logic ensures that this 4499 cast will not fail. 4500 </p> 4501 4502 4503 <h3><a name="BC_UNCONFIRMED_CAST_OF_RETURN_VALUE">BC: Unchecked/unconfirmed cast of return value from method (BC_UNCONFIRMED_CAST_OF_RETURN_VALUE)</a></h3> 4504 4505 4506 <p> 4507 This code performs an unchecked cast of the return value of a method. 4508 The code might be calling the method in such a way that the cast is guaranteed to be 4509 safe, but FindBugs is unable to verify that the cast is safe. Check that your program logic ensures that this 4510 cast will not fail. 4511 </p> 4512 4513 4514 <h3><a name="BC_VACUOUS_INSTANCEOF">BC: instanceof will always return true (BC_VACUOUS_INSTANCEOF)</a></h3> 4515 4516 4517 <p> 4518 This instanceof test will always return true (unless the value being tested is null). 4519 Although this is safe, make sure it isn't 4520 an indication of some misunderstanding or some other logic error. 4521 If you really want to test the value for being null, perhaps it would be clearer to do 4522 better to do a null test rather than an instanceof test. 4523 </p> 4524 4525 4526 <h3><a name="ICAST_QUESTIONABLE_UNSIGNED_RIGHT_SHIFT">BSHIFT: Unsigned right shift cast to short/byte (ICAST_QUESTIONABLE_UNSIGNED_RIGHT_SHIFT)</a></h3> 4527 4528 4529 <p> 4530 The code performs an unsigned right shift, whose result is then 4531 cast to a short or byte, which discards the upper bits of the result. 4532 Since the upper bits are discarded, there may be no difference between 4533 a signed and unsigned right shift (depending upon the size of the shift). 4534 </p> 4535 4536 4537 <h3><a name="CI_CONFUSED_INHERITANCE">CI: Class is final but declares protected field (CI_CONFUSED_INHERITANCE)</a></h3> 4538 4539 4540 <p> 4541 This class is declared to be final, but declares fields to be protected. Since the class 4542 is final, it can not be derived from, and the use of protected is confusing. The access 4543 modifier for the field should be changed to private or public to represent the true 4544 use for the field. 4545 </p> 4546 4547 4548 <h3><a name="DB_DUPLICATE_BRANCHES">DB: Method uses the same code for two branches (DB_DUPLICATE_BRANCHES)</a></h3> 4549 4550 4551 <p> 4552 This method uses the same code to implement two branches of a conditional branch. 4553 Check to ensure that this isn't a coding mistake. 4554 </p> 4555 4556 4557 <h3><a name="DB_DUPLICATE_SWITCH_CLAUSES">DB: Method uses the same code for two switch clauses (DB_DUPLICATE_SWITCH_CLAUSES)</a></h3> 4558 4559 4560 <p> 4561 This method uses the same code to implement two clauses of a switch statement. 4562 This could be a case of duplicate code, but it might also indicate 4563 a coding mistake. 4564 </p> 4565 4566 4567 <h3><a name="DLS_DEAD_LOCAL_STORE">DLS: Dead store to local variable (DLS_DEAD_LOCAL_STORE)</a></h3> 4568 4569 4570 <p> 4571 This instruction assigns a value to a local variable, 4572 but the value is not read or used in any subsequent instruction. 4573 Often, this indicates an error, because the value computed is never 4574 used. 4575 </p> 4576 <p> 4577 Note that Sun's javac compiler often generates dead stores for 4578 final local variables. Because FindBugs is a bytecode-based tool, 4579 there is no easy way to eliminate these false positives. 4580 </p> 4581 4582 4583 <h3><a name="DLS_DEAD_LOCAL_STORE_IN_RETURN">DLS: Useless assignment in return statement (DLS_DEAD_LOCAL_STORE_IN_RETURN)</a></h3> 4584 4585 4586 <p> 4587 This statement assigns to a local variable in a return statement. This assignment 4588 has effect. Please verify that this statement does the right thing. 4589 </p> 4590 4591 4592 <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> 4593 4594 4595 <p>The code stores null into a local variable, and the stored value is not 4596 read. This store may have been introduced to assist the garbage collector, but 4597 as of Java SE 6.0, this is no longer needed or useful. 4598 </p> 4599 4600 4601 <h3><a name="DLS_DEAD_LOCAL_STORE_SHADOWS_FIELD">DLS: Dead store to local variable that shadows field (DLS_DEAD_LOCAL_STORE_SHADOWS_FIELD)</a></h3> 4602 4603 4604 <p> 4605 This instruction assigns a value to a local variable, 4606 but the value is not read or used in any subsequent instruction. 4607 Often, this indicates an error, because the value computed is never 4608 used. There is a field with the same name as the local variable. Did you 4609 mean to assign to that variable instead? 4610 </p> 4611 4612 4613 <h3><a name="DMI_HARDCODED_ABSOLUTE_FILENAME">DMI: Code contains a hard coded reference to an absolute pathname (DMI_HARDCODED_ABSOLUTE_FILENAME)</a></h3> 4614 4615 4616 <p>This code constructs a File object using a hard coded to an absolute pathname 4617 (e.g., <code>new File("/home/dannyc/workspace/j2ee/src/share/com/sun/enterprise/deployment");</code> 4618 </p> 4619 4620 4621 <h3><a name="DMI_NONSERIALIZABLE_OBJECT_WRITTEN">DMI: Non serializable object written to ObjectOutput (DMI_NONSERIALIZABLE_OBJECT_WRITTEN)</a></h3> 4622 4623 4624 <p> 4625 This code seems to be passing a non-serializable object to the ObjectOutput.writeObject method. 4626 If the object is, indeed, non-serializable, an error will result. 4627 </p> 4628 4629 4630 <h3><a name="DMI_USELESS_SUBSTRING">DMI: Invocation of substring(0), which returns the original value (DMI_USELESS_SUBSTRING)</a></h3> 4631 4632 4633 <p> 4634 This code invokes substring(0) on a String, which returns the original value. 4635 </p> 4636 4637 4638 <h3><a name="DMI_THREAD_PASSED_WHERE_RUNNABLE_EXPECTED">Dm: Thread passed where Runnable expected (DMI_THREAD_PASSED_WHERE_RUNNABLE_EXPECTED)</a></h3> 4639 4640 4641 <p> A Thread object is passed as a parameter to a method where 4642 a Runnable is expected. This is rather unusual, and may indicate a logic error 4643 or cause unexpected behavior. 4644 </p> 4645 4646 4647 <h3><a name="EQ_DOESNT_OVERRIDE_EQUALS">Eq: Class doesn't override equals in superclass (EQ_DOESNT_OVERRIDE_EQUALS)</a></h3> 4648 4649 4650 <p> This class extends a class that defines an equals method and adds fields, but doesn't 4651 define an equals method itself. Thus, equality on instances of this class will 4652 ignore the identity of the subclass and the added fields. Be sure this is what is intended, 4653 and that you don't need to override the equals method. Even if you don't need to override 4654 the equals method, consider overriding it anyway to document the fact 4655 that the equals method for the subclass just return the result of 4656 invoking super.equals(o). 4657 </p> 4658 4659 4660 <h3><a name="EQ_UNUSUAL">Eq: Unusual equals method (EQ_UNUSUAL)</a></h3> 4661 4662 4663 <p> This class doesn't do any of the patterns we recognize for checking that the type of the argument 4664 is compatible with the type of the <code>this</code> object. There might not be anything wrong with 4665 this code, but it is worth reviewing. 4666 </p> 4667 4668 4669 <h3><a name="FE_FLOATING_POINT_EQUALITY">FE: Test for floating point equality (FE_FLOATING_POINT_EQUALITY)</a></h3> 4670 4671 4672 <p> 4673 This operation compares two floating point values for equality. 4674 Because floating point calculations may involve rounding, 4675 calculated float and double values may not be accurate. 4676 For values that must be precise, such as monetary values, 4677 consider using a fixed-precision type such as BigDecimal. 4678 For values that need not be precise, consider comparing for equality 4679 within some range, for example: 4680 <code>if ( Math.abs(x - y) < .0000001 )</code>. 4681 See the Java Language Specification, section 4.2.4. 4682 </p> 4683 4684 4685 <h3><a name="VA_FORMAT_STRING_BAD_CONVERSION_TO_BOOLEAN">FS: Non-Boolean argument formatted using %b format specifier (VA_FORMAT_STRING_BAD_CONVERSION_TO_BOOLEAN)</a></h3> 4686 4687 4688 <p> 4689 An argument not of type Boolean is being formatted with a %b format specifier. This won't throw an 4690 exception; instead, it will print true for any nonnull value, and false for null. 4691 This feature of format strings is strange, and may not be what you intended. 4692 </p> 4693 4694 4695 <h3><a name="IA_AMBIGUOUS_INVOCATION_OF_INHERITED_OR_OUTER_METHOD">IA: Potentially ambiguous invocation of either an inherited or outer method (IA_AMBIGUOUS_INVOCATION_OF_INHERITED_OR_OUTER_METHOD)</a></h3> 4696 4697 4698 <p> 4699 An inner class is invoking a method that could be resolved to either a inherited method or a method defined in an outer class. 4700 For example, you invoke <code>foo(17)</code>, which is defined in both a superclass and in an outer method. 4701 By the Java semantics, 4702 it will be resolved to invoke the inherited method, but this may not be want 4703 you intend. 4704 </p> 4705 <p>If you really intend to invoke the inherited method, 4706 invoke it by invoking the method on super (e.g., invoke super.foo(17)), and 4707 thus it will be clear to other readers of your code and to FindBugs 4708 that you want to invoke the inherited method, not the method in the outer class. 4709 </p> 4710 <p>If you call <code>this.foo(17)</code>, then the inherited method will be invoked. However, since FindBugs only looks at 4711 classfiles, it 4712 can't tell the difference between an invocation of <code>this.foo(17)</code> and <code>foo(17)</code>, it will still 4713 complain about a potential ambiguous invocation. 4714 </p> 4715 4716 4717 <h3><a name="IC_INIT_CIRCULARITY">IC: Initialization circularity (IC_INIT_CIRCULARITY)</a></h3> 4718 4719 4720 <p> A circularity was detected in the static initializers of the two 4721 classes referenced by the bug instance. Many kinds of unexpected 4722 behavior may arise from such circularity.</p> 4723 4724 4725 <h3><a name="ICAST_IDIV_CAST_TO_DOUBLE">ICAST: Integral division result cast to double or float (ICAST_IDIV_CAST_TO_DOUBLE)</a></h3> 4726 4727 4728 <p> 4729 This code casts the result of an integral division (e.g., int or long division) 4730 operation to double or 4731 float. 4732 Doing division on integers truncates the result 4733 to the integer value closest to zero. The fact that the result 4734 was cast to double suggests that this precision should have been retained. 4735 What was probably meant was to cast one or both of the operands to 4736 double <em>before</em> performing the division. Here is an example: 4737 </p> 4738 <blockquote> 4739 <pre> 4740 int x = 2; 4741 int y = 5; 4742 // Wrong: yields result 0.0 4743 double value1 = x / y; 4744 4745 // Right: yields result 0.4 4746 double value2 = x / (double) y; 4747 </pre> 4748 </blockquote> 4749 4750 4751 <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> 4752 4753 4754 <p> 4755 This code performs integer multiply and then converts the result to a long, 4756 as in:</p> 4757 <pre> 4758 long convertDaysToMilliseconds(int days) { return 1000*3600*24*days; } 4759 </pre> 4760 <p> 4761 If the multiplication is done using long arithmetic, you can avoid 4762 the possibility that the result will overflow. For example, you 4763 could fix the above code to:</p> 4764 <pre> 4765 long convertDaysToMilliseconds(int days) { return 1000L*3600*24*days; } 4766 </pre> 4767 or 4768 <pre> 4769 static final long MILLISECONDS_PER_DAY = 24L*3600*1000; 4770 long convertDaysToMilliseconds(int days) { return days * MILLISECONDS_PER_DAY; } 4771 </pre> 4772 4773 4774 <h3><a name="IM_AVERAGE_COMPUTATION_COULD_OVERFLOW">IM: Computation of average could overflow (IM_AVERAGE_COMPUTATION_COULD_OVERFLOW)</a></h3> 4775 4776 4777 <p>The code computes the average of two integers using either division or signed right shift, 4778 and then uses the result as the index of an array. 4779 If the values being averaged are very large, this can overflow (resulting in the computation 4780 of a negative average). Assuming that the result is intended to be nonnegative, you 4781 can use an unsigned right shift instead. In other words, rather that using <code>(low+high)/2</code>, 4782 use <code>(low+high) >>> 1</code> 4783 </p> 4784 <p>This bug exists in many earlier implementations of binary search and merge sort. 4785 Martin Buchholz <a href="http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6412541">found and fixed it</a> 4786 in the JDK libraries, and Joshua Bloch 4787 <a href="http://googleresearch.blogspot.com/2006/06/extra-extra-read-all-about-it-nearly.html">widely 4788 publicized the bug pattern</a>. 4789 </p> 4790 4791 4792 <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> 4793 4794 4795 <p> 4796 The code uses x % 2 == 1 to check to see if a value is odd, but this won't work 4797 for negative numbers (e.g., (-5) % 2 == -1). If this code is intending to check 4798 for oddness, consider using x & 1 == 1, or x % 2 != 0. 4799 </p> 4800 4801 4802 <h3><a name="INT_BAD_REM_BY_1">INT: Integer remainder modulo 1 (INT_BAD_REM_BY_1)</a></h3> 4803 4804 4805 <p> Any expression (exp % 1) is guaranteed to always return zero. 4806 Did you mean (exp & 1) or (exp % 2) instead? 4807 </p> 4808 4809 4810 <h3><a name="INT_VACUOUS_BIT_OPERATION">INT: Vacuous bit mask operation on integer value (INT_VACUOUS_BIT_OPERATION)</a></h3> 4811 4812 4813 <p> This is an integer bit operation (and, or, or exclusive or) that doesn't do any useful work 4814 (e.g., <code>v & 0xffffffff</code>). 4815 4816 </p> 4817 4818 4819 <h3><a name="INT_VACUOUS_COMPARISON">INT: Vacuous comparison of integer value (INT_VACUOUS_COMPARISON)</a></h3> 4820 4821 4822 <p> There is an integer comparison that always returns 4823 the same value (e.g., x <= Integer.MAX_VALUE). 4824 </p> 4825 4826 4827 <h3><a name="MTIA_SUSPECT_SERVLET_INSTANCE_FIELD">MTIA: Class extends Servlet class and uses instance variables (MTIA_SUSPECT_SERVLET_INSTANCE_FIELD)</a></h3> 4828 4829 4830 <p> 4831 This class extends from a Servlet class, and uses an instance member variable. Since only 4832 one instance of a Servlet class is created by the J2EE framework, and used in a 4833 multithreaded way, this paradigm is highly discouraged and most likely problematic. Consider 4834 only using method local variables. 4835 </p> 4836 4837 4838 <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> 4839 4840 4841 <p> 4842 This class extends from a Struts Action class, and uses an instance member variable. Since only 4843 one instance of a struts Action class is created by the Struts framework, and used in a 4844 multithreaded way, this paradigm is highly discouraged and most likely problematic. Consider 4845 only using method local variables. Only instance fields that are written outside of a monitor 4846 are reported. 4847 </p> 4848 4849 4850 <h3><a name="NP_DEREFERENCE_OF_READLINE_VALUE">NP: Dereference of the result of readLine() without nullcheck (NP_DEREFERENCE_OF_READLINE_VALUE)</a></h3> 4851 4852 4853 <p> The result of invoking readLine() is dereferenced without checking to see if the result is null. If there are no more lines of text 4854 to read, readLine() will return null and dereferencing that will generate a null pointer exception. 4855 </p> 4856 4857 4858 <h3><a name="NP_IMMEDIATE_DEREFERENCE_OF_READLINE">NP: Immediate dereference of the result of readLine() (NP_IMMEDIATE_DEREFERENCE_OF_READLINE)</a></h3> 4859 4860 4861 <p> The result of invoking readLine() is immediately dereferenced. If there are no more lines of text 4862 to read, readLine() will return null and dereferencing that will generate a null pointer exception. 4863 </p> 4864 4865 4866 <h3><a name="NP_LOAD_OF_KNOWN_NULL_VALUE">NP: Load of known null value (NP_LOAD_OF_KNOWN_NULL_VALUE)</a></h3> 4867 4868 4869 <p> The variable referenced at this point is known to be null due to an earlier 4870 check against null. Although this is valid, it might be a mistake (perhaps you 4871 intended to refer to a different variable, or perhaps the earlier check to see if the 4872 variable is null should have been a check to see if it was nonnull). 4873 </p> 4874 4875 4876 <h3><a name="NP_METHOD_PARAMETER_TIGHTENS_ANNOTATION">NP: Method tightens nullness annotation on parameter (NP_METHOD_PARAMETER_TIGHTENS_ANNOTATION)</a></h3> 4877 4878 <p> 4879 A method should always implement the contract of a method it overrides. Thus, if a method takes a parameter 4880 that is marked as @Nullable, you shouldn't override that method in a subclass with a method where that parameter is @Nonnull. 4881 Doing so violates the contract that the method should handle a null parameter. 4882 </p> 4883 4884 <h3><a name="NP_METHOD_RETURN_RELAXING_ANNOTATION">NP: Method relaxes nullness annotation on return value (NP_METHOD_RETURN_RELAXING_ANNOTATION)</a></h3> 4885 4886 <p> 4887 A method should always implement the contract of a method it overrides. Thus, if a method takes is annotated 4888 as returning a @Nonnull value, 4889 you shouldn't override that method in a subclass with a method annotated as returning a @Nullable or @CheckForNull value. 4890 Doing so violates the contract that the method shouldn't return null. 4891 </p> 4892 4893 <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> 4894 4895 4896 <p> The return value from a method is dereferenced without a null check, 4897 and the return value of that method is one that should generally be checked 4898 for null. This may lead to a <code>NullPointerException</code> when the code is executed. 4899 </p> 4900 4901 4902 <h3><a name="NP_NULL_ON_SOME_PATH_MIGHT_BE_INFEASIBLE">NP: Possible null pointer dereference on branch that might be infeasible (NP_NULL_ON_SOME_PATH_MIGHT_BE_INFEASIBLE)</a></h3> 4903 4904 4905 <p> There is a branch of statement that, <em>if executed,</em> guarantees that 4906 a null value will be dereferenced, which 4907 would generate a <code>NullPointerException</code> when the code is executed. 4908 Of course, the problem might be that the branch or statement is infeasible and that 4909 the null pointer exception can't ever be executed; deciding that is beyond the ability of FindBugs. 4910 Due to the fact that this value had been previously tested for nullness, 4911 this is a definite possibility. 4912 </p> 4913 4914 4915 <h3><a name="NP_PARAMETER_MUST_BE_NONNULL_BUT_MARKED_AS_NULLABLE">NP: Parameter must be nonnull but is marked as nullable (NP_PARAMETER_MUST_BE_NONNULL_BUT_MARKED_AS_NULLABLE)</a></h3> 4916 4917 4918 <p> This parameter is always used in a way that requires it to be nonnull, 4919 but the parameter is explicitly annotated as being Nullable. Either the use 4920 of the parameter or the annotation is wrong. 4921 </p> 4922 4923 4924 <h3><a name="NP_UNWRITTEN_PUBLIC_OR_PROTECTED_FIELD">NP: Read of unwritten public or protected field (NP_UNWRITTEN_PUBLIC_OR_PROTECTED_FIELD)</a></h3> 4925 4926 4927 <p> The program is dereferencing a public or protected 4928 field that does not seem to ever have a non-null value written to it. 4929 Unless the field is initialized via some mechanism not seen by the analysis, 4930 dereferencing this value will generate a null pointer exception. 4931 </p> 4932 4933 4934 <h3><a name="NS_DANGEROUS_NON_SHORT_CIRCUIT">NS: Potentially dangerous use of non-short-circuit logic (NS_DANGEROUS_NON_SHORT_CIRCUIT)</a></h3> 4935 4936 4937 <p> This code seems to be using non-short-circuit logic (e.g., & 4938 or |) 4939 rather than short-circuit logic (&& or ||). In addition, 4940 it seem possible that, depending on the value of the left hand side, you might not 4941 want to evaluate the right hand side (because it would have side effects, could cause an exception 4942 or could be expensive.</p> 4943 <p> 4944 Non-short-circuit logic causes both sides of the expression 4945 to be evaluated even when the result can be inferred from 4946 knowing the left-hand side. This can be less efficient and 4947 can result in errors if the left-hand side guards cases 4948 when evaluating the right-hand side can generate an error. 4949 </p> 4950 4951 <p>See <a href="http://java.sun.com/docs/books/jls/third_edition/html/expressions.html#15.22.2">the Java 4952 Language Specification</a> for details 4953 4954 </p> 4955 4956 4957 <h3><a name="NS_NON_SHORT_CIRCUIT">NS: Questionable use of non-short-circuit logic (NS_NON_SHORT_CIRCUIT)</a></h3> 4958 4959 4960 <p> This code seems to be using non-short-circuit logic (e.g., & 4961 or |) 4962 rather than short-circuit logic (&& or ||). 4963 Non-short-circuit logic causes both sides of the expression 4964 to be evaluated even when the result can be inferred from 4965 knowing the left-hand side. This can be less efficient and 4966 can result in errors if the left-hand side guards cases 4967 when evaluating the right-hand side can generate an error. 4968 4969 <p>See <a href="http://java.sun.com/docs/books/jls/third_edition/html/expressions.html#15.22.2">the Java 4970 Language Specification</a> for details 4971 4972 </p> 4973 4974 4975 <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> 4976 4977 4978 <p> It is often a better design to 4979 return a length zero array rather than a null reference to indicate that there 4980 are no results (i.e., an empty list of results). 4981 This way, no explicit check for null is needed by clients of the method.</p> 4982 4983 <p>On the other hand, using null to indicate 4984 "there is no answer to this question" is probably appropriate. 4985 For example, <code>File.listFiles()</code> returns an empty list 4986 if given a directory containing no files, and returns null if the file 4987 is not a directory.</p> 4988 4989 4990 <h3><a name="QF_QUESTIONABLE_FOR_LOOP">QF: Complicated, subtle or wrong increment in for-loop (QF_QUESTIONABLE_FOR_LOOP)</a></h3> 4991 4992 4993 <p>Are you sure this for loop is incrementing the correct variable? 4994 It appears that another variable is being initialized and checked 4995 by the for loop. 4996 </p> 4997 4998 4999 <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> 5000 5001 5002 <p> This method contains a reference known to be non-null with another reference 5003 known to be null.</p> 5004 5005 5006 <h3><a name="RCN_REDUNDANT_COMPARISON_TWO_NULL_VALUES">RCN: Redundant comparison of two null values (RCN_REDUNDANT_COMPARISON_TWO_NULL_VALUES)</a></h3> 5007 5008 5009 <p> This method contains a redundant comparison of two references known to 5010 both be definitely null.</p> 5011 5012 5013 <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> 5014 5015 5016 <p> This method contains a redundant check of a known non-null value against 5017 the constant null.</p> 5018 5019 5020 <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> 5021 5022 5023 <p> This method contains a redundant check of a known null value against 5024 the constant null.</p> 5025 5026 5027 <h3><a name="REC_CATCH_EXCEPTION">REC: Exception is caught when Exception is not thrown (REC_CATCH_EXCEPTION)</a></h3> 5028 5029 5030 <p> 5031 This method uses a try-catch block that catches Exception objects, but Exception is not 5032 thrown within the try block, and RuntimeException is not explicitly caught. It is a common bug pattern to 5033 say try { ... } catch (Exception e) { something } as a shorthand for catching a number of types of exception 5034 each of whose catch blocks is identical, but this construct also accidentally catches RuntimeException as well, 5035 masking potential bugs. 5036 </p> 5037 <p>A better approach is to either explicitly catch the specific exceptions that are thrown, 5038 or to explicitly catch RuntimeException exception, rethrow it, and then catch all non-Runtime Exceptions, as shown below:</p> 5039 <pre> 5040 try { 5041 ... 5042 } catch (RuntimeException e) { 5043 throw e; 5044 } catch (Exception e) { 5045 ... deal with all non-runtime exceptions ... 5046 }</pre> 5047 5048 5049 <h3><a name="RI_REDUNDANT_INTERFACES">RI: Class implements same interface as superclass (RI_REDUNDANT_INTERFACES)</a></h3> 5050 5051 5052 <p> 5053 This class declares that it implements an interface that is also implemented by a superclass. 5054 This is redundant because once a superclass implements an interface, all subclasses by default also 5055 implement this interface. It may point out that the inheritance hierarchy has changed since 5056 this class was created, and consideration should be given to the ownership of 5057 the interface's implementation. 5058 </p> 5059 5060 5061 <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> 5062 5063 5064 <p> The method invokes String.indexOf and checks to see if the result is positive or non-positive. 5065 It is much more typical to check to see if the result is negative or non-negative. It is 5066 positive only if the substring checked for occurs at some place other than at the beginning of 5067 the String.</p> 5068 5069 5070 <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> 5071 5072 5073 <p> The value returned by readLine is discarded after checking to see if the return 5074 value is non-null. In almost all situations, if the result is non-null, you will want 5075 to use that non-null value. Calling readLine again will give you a different line.</p> 5076 5077 5078 <h3><a name="RV_REM_OF_HASHCODE">RV: Remainder of hashCode could be negative (RV_REM_OF_HASHCODE)</a></h3> 5079 5080 5081 <p> This code computes a hashCode, and then computes 5082 the remainder of that value modulo another value. Since the hashCode 5083 can be negative, the result of the remainder operation 5084 can also be negative. </p> 5085 <p> Assuming you want to ensure that the result of your computation is nonnegative, 5086 you may need to change your code. 5087 If you know the divisor is a power of 2, 5088 you can use a bitwise and operator instead (i.e., instead of 5089 using <code>x.hashCode()%n</code>, use <code>x.hashCode()&(n-1)</code>. 5090 This is probably faster than computing the remainder as well. 5091 If you don't know that the divisor is a power of 2, take the absolute 5092 value of the result of the remainder operation (i.e., use 5093 <code>Math.abs(x.hashCode()%n)</code> 5094 </p> 5095 5096 5097 <h3><a name="RV_REM_OF_RANDOM_INT">RV: Remainder of 32-bit signed random integer (RV_REM_OF_RANDOM_INT)</a></h3> 5098 5099 5100 <p> This code generates a random signed integer and then computes 5101 the remainder of that value modulo another value. Since the random 5102 number can be negative, the result of the remainder operation 5103 can also be negative. Be sure this is intended, and strongly 5104 consider using the Random.nextInt(int) method instead. 5105 </p> 5106 5107 5108 <h3><a name="RV_RETURN_VALUE_IGNORED_INFERRED">RV: Method ignores return value, is this OK? (RV_RETURN_VALUE_IGNORED_INFERRED)</a></h3> 5109 5110 5111 <p>This code calls a method and ignores the return value. The return value 5112 is the same type as the type the method is invoked on, and from our analysis it looks 5113 like the return value might be important (e.g., like ignoring the 5114 return value of <code>String.toLowerCase()</code>). 5115 </p> 5116 <p>We are guessing that ignoring the return value might be a bad idea just from 5117 a simple analysis of the body of the method. You can use a @CheckReturnValue annotation 5118 to instruct FindBugs as to whether ignoring the return value of this method 5119 is important or acceptable. 5120 </p> 5121 <p>Please investigate this closely to decide whether it is OK to ignore the return value. 5122 </p> 5123 5124 5125 <h3><a name="SA_FIELD_DOUBLE_ASSIGNMENT">SA: Double assignment of field (SA_FIELD_DOUBLE_ASSIGNMENT)</a></h3> 5126 5127 5128 <p> This method contains a double assignment of a field; e.g. 5129 </p> 5130 <pre> 5131 int x,y; 5132 public void foo() { 5133 x = x = 17; 5134 } 5135 </pre> 5136 <p>Assigning to a field twice is useless, and may indicate a logic error or typo.</p> 5137 5138 5139 <h3><a name="SA_LOCAL_DOUBLE_ASSIGNMENT">SA: Double assignment of local variable (SA_LOCAL_DOUBLE_ASSIGNMENT)</a></h3> 5140 5141 5142 <p> This method contains a double assignment of a local variable; e.g. 5143 </p> 5144 <pre> 5145 public void foo() { 5146 int x,y; 5147 x = x = 17; 5148 } 5149 </pre> 5150 <p>Assigning the same value to a variable twice is useless, and may indicate a logic error or typo.</p> 5151 5152 5153 <h3><a name="SA_LOCAL_SELF_ASSIGNMENT">SA: Self assignment of local variable (SA_LOCAL_SELF_ASSIGNMENT)</a></h3> 5154 5155 5156 <p> This method contains a self assignment of a local variable; e.g.</p> 5157 <pre> 5158 public void foo() { 5159 int x = 3; 5160 x = x; 5161 } 5162 </pre> 5163 <p> 5164 Such assignments are useless, and may indicate a logic error or typo. 5165 </p> 5166 5167 5168 <h3><a name="SF_SWITCH_FALLTHROUGH">SF: Switch statement found where one case falls through to the next case (SF_SWITCH_FALLTHROUGH)</a></h3> 5169 5170 5171 <p> This method contains a switch statement where one case branch will fall through to the next case. 5172 Usually you need to end this case with a break or return.</p> 5173 5174 5175 <h3><a name="SF_SWITCH_NO_DEFAULT">SF: Switch statement found where default case is missing (SF_SWITCH_NO_DEFAULT)</a></h3> 5176 5177 5178 <p> This method contains a switch statement where default case is missing. 5179 Usually you need to provide a default case.</p> 5180 <p>Because the analysis only looks at the generated bytecode, this warning can be incorrect triggered if 5181 the default case is at the end of the switch statement and doesn't end with a break statement. 5182 5183 5184 <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> 5185 5186 5187 <p> This instance method writes to a static field. This is tricky to get 5188 correct if multiple instances are being manipulated, 5189 and generally bad practice. 5190 </p> 5191 5192 5193 <h3><a name="SE_PRIVATE_READ_RESOLVE_NOT_INHERITED">Se: Private readResolve method not inherited by subclasses (SE_PRIVATE_READ_RESOLVE_NOT_INHERITED)</a></h3> 5194 5195 5196 <p> This class defines a private readResolve method. Since it is private, it won't be inherited by subclasses. 5197 This might be intentional and OK, but should be reviewed to ensure it is what is intended. 5198 </p> 5199 5200 5201 <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> 5202 5203 5204 <p> The field is marked as transient, but the class isn't Serializable, so marking it as transient 5205 has absolutely no effect. 5206 This may be leftover marking from a previous version of the code in which the class was transient, or 5207 it may indicate a misunderstanding of how serialization works. 5208 </p> 5209 5210 5211 <h3><a name="TQ_EXPLICIT_UNKNOWN_SOURCE_VALUE_REACHES_ALWAYS_SINK">TQ: Value required to have type qualifier, but marked as unknown (TQ_EXPLICIT_UNKNOWN_SOURCE_VALUE_REACHES_ALWAYS_SINK)</a></h3> 5212 5213 5214 <p> 5215 A value is used in a way that requires it to be always be a value denoted by a type qualifier, but 5216 there is an explicit annotation stating that it is not known where the value is required to have that type qualifier. 5217 Either the usage or the annotation is incorrect. 5218 </p> 5219 5220 5221 <h3><a name="TQ_EXPLICIT_UNKNOWN_SOURCE_VALUE_REACHES_NEVER_SINK">TQ: Value required to not have type qualifier, but marked as unknown (TQ_EXPLICIT_UNKNOWN_SOURCE_VALUE_REACHES_NEVER_SINK)</a></h3> 5222 5223 5224 <p> 5225 A value is used in a way that requires it to be never be a value denoted by a type qualifier, but 5226 there is an explicit annotation stating that it is not known where the value is prohibited from having that type qualifier. 5227 Either the usage or the annotation is incorrect. 5228 </p> 5229 5230 5231 <h3><a name="UCF_USELESS_CONTROL_FLOW">UCF: Useless control flow (UCF_USELESS_CONTROL_FLOW)</a></h3> 5232 5233 5234 <p> This method contains a useless control flow statement, where 5235 control flow continues onto the same place regardless of whether or not 5236 the branch is taken. For example, 5237 this is caused by having an empty statement 5238 block for an <code>if</code> statement:</p> 5239 <pre> 5240 if (argv.length == 0) { 5241 // TODO: handle this case 5242 } 5243 </pre> 5244 5245 5246 <h3><a name="UCF_USELESS_CONTROL_FLOW_NEXT_LINE">UCF: Useless control flow to next line (UCF_USELESS_CONTROL_FLOW_NEXT_LINE)</a></h3> 5247 5248 5249 <p> This method contains a useless control flow statement in which control 5250 flow follows to the same or following line regardless of whether or not 5251 the branch is taken. 5252 Often, this is caused by inadvertently using an empty statement as the 5253 body of an <code>if</code> statement, e.g.:</p> 5254 <pre> 5255 if (argv.length == 1); 5256 System.out.println("Hello, " + argv[0]); 5257 </pre> 5258 5259 5260 <h3><a name="URF_UNREAD_PUBLIC_OR_PROTECTED_FIELD">UrF: Unread public/protected field (URF_UNREAD_PUBLIC_OR_PROTECTED_FIELD)</a></h3> 5261 5262 5263 <p> This field is never read. 5264 The field is public or protected, so perhaps 5265 it is intended to be used with classes not seen as part of the analysis. If not, 5266 consider removing it from the class.</p> 5267 5268 5269 <h3><a name="UUF_UNUSED_PUBLIC_OR_PROTECTED_FIELD">UuF: Unused public or protected field (UUF_UNUSED_PUBLIC_OR_PROTECTED_FIELD)</a></h3> 5270 5271 5272 <p> This field is never used. 5273 The field is public or protected, so perhaps 5274 it is intended to be used with classes not seen as part of the analysis. If not, 5275 consider removing it from the class.</p> 5276 5277 5278 <h3><a name="UWF_FIELD_NOT_INITIALIZED_IN_CONSTRUCTOR">UwF: Field not initialized in constructor but dereferenced without null check (UWF_FIELD_NOT_INITIALIZED_IN_CONSTRUCTOR)</a></h3> 5279 5280 5281 <p> This field is never initialized within any constructor, and is therefore could be null after 5282 the object is constructed. Elsewhere, it is loaded and dereferenced without a null check. 5283 This could be a either an error or a questionable design, since 5284 it means a null pointer exception will be generated if that field is dereferenced 5285 before being initialized. 5286 </p> 5287 5288 5289 <h3><a name="UWF_UNWRITTEN_PUBLIC_OR_PROTECTED_FIELD">UwF: Unwritten public or protected field (UWF_UNWRITTEN_PUBLIC_OR_PROTECTED_FIELD)</a></h3> 5290 5291 5292 <p> No writes were seen to this public/protected field. All reads of it will return the default 5293 value. Check for errors (should it have been initialized?), or remove it if it is useless.</p> 5294 5295 5296 <h3><a name="XFB_XML_FACTORY_BYPASS">XFB: Method directly allocates a specific implementation of xml interfaces (XFB_XML_FACTORY_BYPASS)</a></h3> 5297 5298 5299 <p> 5300 This method allocates a specific implementation of an xml interface. It is preferable to use 5301 the supplied factory classes to create these objects so that the implementation can be 5302 changed at runtime. See 5303 </p> 5304 <ul> 5305 <li>javax.xml.parsers.DocumentBuilderFactory</li> 5306 <li>javax.xml.parsers.SAXParserFactory</li> 5307 <li>javax.xml.transform.TransformerFactory</li> 5308 <li>org.w3c.dom.Document.create<i>XXXX</i></li> 5309 </ul> 5310 <p>for details.</p> 5311 5312 5313 5314 5315 <hr> <p> 5316 <script language="JavaScript" type="text/javascript"> 5317 <!---//hide script from old browsers 5318 document.write( "Last updated "+ document.lastModified + "." ); 5319 //end hiding contents ---> 5320 </script> 5321 <p> Send comments to <a class="sidebar" href="mailto:findbugs (a] cs.umd.edu">findbugs (a] cs.umd.edu</a> 5322 <p> 5323 <A href="http://sourceforge.net"><IMG src="http://sourceforge.net/sflogo.php?group_id=96405&type=5" width="210" height="62" border="0" alt="SourceForge.net Logo" /></A> 5324 </td></tr></table> 5325 </body></html> 5326
