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> 468The <code>equals(Object o)</code> method shouldn't make any assumptions 469about the type of <code>o</code>. It should simply return 470false 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 480lead to unexpected results (of course depending on the value of 481SWT.SELECTED). If SWT.SELECTED is a negative number, this is a candidate 482for a bug. Even when SWT.SELECTED is not negative, it seems good practice 483to 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(). 502If this class ("<i>A</i>") is extended by a subclass ("<i>B</i>"), 503and 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>, 505which violates the standard contract for clone().</p> 506 507<p> If all clone() methods call super.clone(), then they are guaranteed 508to 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. 515There are some situations in which this is OK (e.g., you want to control how subclasses 516can 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 571the Random object. This produces mediocre quality random numbers and is inefficient. 572If possible, rewrite the code so that the Random object is created once and saved, and each time a new random number 573is 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 577number; 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>, 586not <code>c.removeAll(c)</code>. Calling <code>c.removeAll(c)</code> to clear a collection 587is less clear, susceptible to errors from typos, less efficient and 588for 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 605or Runtime.runFinalizersOnExit for any reason: they are among the most 606dangerous 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 613equality using the == or != operators. Requiring callers to 614pass only String constants or interned strings to a method is unnecessarily 615fragile, and rarely leads to measurable performance gains. Consider 616using 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 623equality using the == or != operators. 624Unless both strings are either constants in a source file, or have been 625interned using the <code>String.intern()</code> method, the same string 626value may be represented by two different String objects. Consider 627using 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 644the equals method). For example, the Foo class might have an equals method 645that looks like: 646</p> 647<pre> 648public 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 657is 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> 674It is strongly recommended, but not strictly required that <code>(x.compareTo(y)==0) == (x.equals(y))</code>. 675Generally speaking, any class that implements the Comparable interface and violates this condition 676should clearly indicate this fact. The recommended language 677is "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. 685It compares a class literal with the class of the argument (e.g., in class <code>Foo</code> 686it might check if <code>Foo.class == o.getClass()</code>). 687It 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 714finalize method on all the finalizable object, possibly at the same time in different threads. 715Thus, it is a particularly bad idea, in the finalize method for a class X, invoke finalize 716on 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 730the object be garbage collected, finalized, and then garbage collected again. You should just remove the finalize 731method. 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> 764This 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, 800the 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, 827the 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. 854That subclass will not yet be initialized at the time of this use. 855For example, in the following code, <code>foo</code> will be null.</p> 856 857<pre> 858public 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 881does 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> 898This code seems to be storing a non-serializable object into an HttpSession. 899If 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 964be 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> 977Names 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 985in 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 993any code that references this API, 994will 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> 1002Methods 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 1010that the interface is in a different package (e.g., <code>alpha.Foo</code> extends <code>beta.Foo</code>). 1011This can be exceptionally confusing, create lots of situations in which you have to look at import statements 1012to resolve references and creates many 1013opportunities 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 1021that its superclass is in a different package (e.g., <code>alpha.Foo</code> extends <code>beta.Foo</code>). 1022This can be exceptionally confusing, create lots of situations in which you have to look at import statements 1023to resolve references and creates many 1024opportunities 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. 1032This is very confusing because if the capitalization were 1033identical then one of the methods would override the other. From the existence of other methods, it 1034seems that the existence of both of these methods is intentional, but is sure is confusing. 1035You 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 1043the type of the corresponding parameter in the superclass. For example, if you have:</p> 1044 1045<blockquote> 1046<pre> 1047import alpha.Foo; 1048public class A { 1049 public int f(Foo x) { return 17; } 1050} 1051---- 1052import beta.Foo; 1053public 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 1061override the 1062<code>f(Foo)</code> method defined in class <code>A</code>, because the argument 1063types 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, 1067so this is presumably understood. However, such methods are exceptionally confusing. You should strongly consider 1068removing 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 1076or row set), does not assign it to any 1077fields, pass it to other methods, or return it, and does not appear to close 1078the object on all paths out of the method. Failure to 1079close database resources on all paths out of a method may 1080result in poor performance, and could cause the application to 1081have 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 1089or row set), does not assign it to any 1090fields, pass it to other methods, or return it, and does not appear to close 1091the object on all exception paths out of the method. Failure to 1092close database resources on all paths out of a method may 1093result in poor performance, and could cause the application to 1094have 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 1101fields, pass it to other methods that might close it, 1102or return it, and does not appear to close 1103the stream on all paths out of the method. This may result in 1104a file descriptor leak. It is generally a good 1105idea to use a <code>finally</code> block to ensure that streams are 1106closed.</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 1113fields, pass it to other methods, or return it, and does not appear to close 1114it on all possible exception paths out of the method. 1115This may result in a file descriptor leak. It is generally a good 1116idea to use a <code>finally</code> block to ensure that streams are 1117closed.</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, 1138where the correct way to compare instances of this type is generally 1139with the equals() method. 1140It is possible to create distinct instances that are equal but do not compare as == since 1141they are different objects. 1142Examples of classes which should generally 1143not 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. 1150Normally, there are only two Boolean values (Boolean.TRUE and Boolean.FALSE), 1151but it is possible to create other Boolean objects using the <code>new Boolean(b)</code> 1152constructor. It is best to avoid such objects, but if they do exist, 1153then checking Boolean objects for equality using == or != will give results 1154than 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. 1188This is a questionable or bad programming practice, since if the return 1189value is Integer.MIN_VALUE, negating the return value won't 1190negate the sign of the result. You can achieve the same intended result 1191by 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 1199since it can indicate an unusual or unexpected function execution. For 1200example, the <code>File.delete()</code> method returns false 1201if the file could not be successfully deleted (rather than 1202throwing an Exception). 1203If you don't check the result, you won't notice if the method invocation 1204signals 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 1212before 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 1219show(), setVisible(), and pack() will create the associated peer for the frame. 1220With the creation of the peer, the system creates the event dispatch thread. 1221This makes things problematic because the event dispatch thread could be notifying 1222listeners while pack and validate are still processing. This situation could result in 1223two threads going through the Swing component-based GUI -- it's a serious flaw that 1224could result in deadlocks or other related threading issues. A pack call causes 1225components to be realized. As they are being realized (that is, not necessarily 1226visible), 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, 1234Serializable, or <code>java.lang.Object</code>, and does not appear to implement 1235the <code>Externalizable</code> interface or the 1236<code>readObject()</code> and <code>writeObject()</code> methods. 1237Objects of this class will not be deserialized correctly if a non-Serializable 1238object 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. 1245Thus, attempts to serialize it will also attempt to associate instance of the outer 1246class 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 1249problem. Making the outer class serializable might also work, but that would 1250mean serializing an instance of the inner class would always also serialize the instance 1251of 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 1258of 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 1265should consider whether or not it should also implement the <code>Serializable</code> 1266interface. If a comparator is used to construct an ordered collection 1267such as a <code>TreeMap</code>, then the <code>TreeMap</code> 1268will be serializable only if the comparator is also serializable. 1269As most comparators have little or no state, making them serializable 1270is 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 1278it will also serialize the associated outer instance. The outer instance is serializable, 1279so this won't fail, but it might serialize a lot more data than intended. 1280If possible, making the inner class a static inner class (also known as a nested class) should solve the 1281problem. 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 1336mechanism, 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 1344deserialized 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 1369results other than expected if this class is extended by a class in 1370another package.</p> 1371 1372 1373<h3><a name="BC_IMPOSSIBLE_CAST">BC: Impossible cast (BC_IMPOSSIBLE_CAST)</a></h3> 1374 1375 1376<p> 1377This cast will always throw a ClassCastException. 1378FindBugs tracks type information from instanceof checks, 1379and also uses more precise information about the types 1380of values returned from methods and loaded from fields. 1381Thus, it may have more precise information that just 1382the declared type of a variable, and can use this to determine 1383that 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> 1392This cast will always throw a ClassCastException. 1393The analysis believes it knows 1394the precise type of the value being cast, and the attempt to 1395downcast 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> 1403This code is casting the result of calling <code>toArray()</code> on a collection 1404to a type more specific than <code>Object[]</code>, as in:</p> 1405<pre> 1406String[] 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> 1411of almost all collections return an <code>Object[]</code>. They can't really do anything else, 1412since 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> 1417method of lists returned by <code>Arrays.asList(...)</code> will return a covariantly 1418typed array. For example, <code>Arrays.asArray(new String[] { "a" }).toArray()</code> 1419will return a <code>String []</code>. FindBugs attempts to detect and suppress 1420such 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> 1428This instanceof test will always return false. Although this is safe, make sure it isn't 1429an 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. 1437Values loaded from a byte array are sign extended to 32 bits 1438before any any bitwise operations are performed on the value. 1439Thus, 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> 1442to 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> 1448int result = 0; 1449for(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> 1455int result = 0; 1456for(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, 1466which will always compare unequal 1467due to the specific values of constants C and D. 1468This 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, 1475which will always compare equal. 1476This 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. 1483which will always compare unequal 1484due to the specific values of constants C and D. 1485This may indicate a logic error or typo.</p> 1486 1487<p> Typically, this bug occurs because the code wants to perform 1488a membership test in a bit set, but uses the bitwise OR 1489operator ("|") 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 1496with return type byte) and performs a bitwise OR with 1497that value. Byte values are sign extended to 32 bits 1498before any any bitwise operations are performed on the value. 1499Thus, 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> 1502to 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> 1508int result = 0; 1509for(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> 1515int result = 0; 1516for(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 1528lead to unexpected results (of course depending on the value of 1529SWT.SELECTED). If SWT.SELECTED is a negative number, this is a candidate 1530for a bug. Even when SWT.SELECTED is not negative, it seems good practice 1531to 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 1542a listener defined in the java.awt.event or javax.swing.event package. As a result, this method will not 1543get 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> 1550The code performs shift of a 32 bit int by a constant amount outside 1551the range -31..31. 1552The effect of this is to use the lower 5 bits of the integer 1553value to decide how much to shift by (e.g., shifting by 40 bits is the same as shifting by 8 bits, 1554and shifting by 32 bits is the same as shifting by zero bits). This probably isn't what was expected, 1555and 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 1563evaluation of a conditional ternary operator (the <code> b ? e1 : e2</code> operator). The 1564semantics of Java mandate that if <code>e1</code> and <code>e2</code> are wrapped 1565numeric values, the values are unboxed and converted/coerced to their common type (e.g, 1566if <code>e1</code> is of type <code>Integer</code> 1567and <code>e2</code> is of type <code>Float</code>, then <code>e1</code> is unboxed, 1568converted 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 1576the 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>. 1587A postfix increment/decrement does not impact the value of the expression, 1588so this increment/decrement has no effect. 1589Please 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> 1597This 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> 1599In Java 1.4 and earlier, a reference to <code>Foo.class</code> would force the static initializer 1600for <code>Foo</code> to be executed, if it has not been executed already. 1601In 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> 1604for 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> 1612The code performs an increment operation (e.g., <code>i++</code>) and then 1613immediately overwrites it. For example, <code>i = i++</code> immediately 1614overwrites 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. 1622For example, a call <code>Preconditions.checkNotNull("message", message)</code> 1623has 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> 1631This code passes a constant month 1632value 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> 1640This code creates a BigDecimal from a double value that doesn't translate well to a 1641decimal number. 1642For 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. 1643You probably want to use the BigDecimal.valueOf(double d) method, which uses the String representation 1644of 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> 1653The hasNext() method invokes the next() method. This is almost certainly wrong, 1654since the hasNext() method is not supposed to change the state of the iterator, 1655and 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 1663itself (e.g., if <code>s.contains(s)</code> were true). This is unlikely to be true and would cause 1664problems if it were true (such as the computation of the hash code resulting in infinite recursion). 1665It 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> 1673This 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> 1682The code invokes hashCode on an array. Calling hashCode on 1683an array returns the same value as System.identityHashCode, and ingores 1684the contents and length of the array. If you need a hashCode that 1685depends on the contents of an array <code>a</code>, 1686use <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 1704always 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>) 1720While 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>) 1729A 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> 1746This method invokes the .equals(Object o) to compare an array and a reference that doesn't seem 1747to be an array. If things being compared are of different types, they are guaranteed to be unequal 1748and the comparison is almost certainly an error. Even if they are both arrays, the equals method 1749on arrays only determines of the two arrays are the same object. 1750To compare the 1751contents 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> 1759This method invokes the .equals(Object o) method on an array. Since arrays do not override the equals 1760method of Object, calling equals on an array is the same as comparing their addresses. To compare the 1761contents of the arrays, use <code>java.util.Arrays.equals(Object[], Object[])</code>. 1762To compare the addresses of the arrays, it would be 1763less 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> 1771This method invokes the .equals(Object o) to compare two arrays, but the arrays of 1772of incompatible types (e.g., String[] and StringBuffer[], or String[] and int[]). 1773They will never be equal. In addition, when equals(...) is used to compare arrays it 1774only 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 1782the argument. According to the contract of the equals() method, 1783this 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> 1790This method calls equals(Object) on two references, one of which is a class 1791and the other an interface, where neither the class nor any of its 1792non-abstract subclasses implement the interface. 1793Therefore, the objects being compared 1794are unlikely to be members of the same class at runtime 1795(unless some application classes were not analyzed, or dynamic class 1796loading can occur at runtime). 1797According to the contract of equals(), 1798objects of different 1799classes should always compare as unequal; therefore, according to the 1800contract defined by java.lang.Object.equals(Object), 1801the 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 1809interface types, where neither is a subtype of the other, 1810and there are no known non-abstract classes which implement both interfaces. 1811Therefore, the objects being compared 1812are unlikely to be members of the same class at runtime 1813(unless some application classes were not analyzed, or dynamic class 1814loading can occur at runtime). 1815According to the contract of equals(), 1816objects of different 1817classes should always compare as unequal; therefore, according to the 1818contract defined by java.lang.Object.equals(Object), 1819the 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 1827class types with no common subclasses. 1828Therefore, the objects being compared 1829are unlikely to be members of the same class at runtime 1830(unless some application classes were not analyzed, or dynamic class 1831loading can occur at runtime). 1832According to the contract of equals(), 1833objects of different 1834classes should always compare as unequal; therefore, according to the 1835contract defined by java.lang.Object.equals(Object), 1836the 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 1844different 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 1852that 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 1854superclass, you can use use:</p> 1855<pre> 1856public 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. 1864Plus, 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 1872of their classes are equal. You can have different classes with the same name if they are loaded by 1873different 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 1881using object identity. Defining a covariant equals method for an enumeration 1882value is exceptionally bad practice, since it would likely result 1883in having two different enumeration values that compare as equals using 1884the covariant enum method, and as not equal when compared normally. 1885Don'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 1914methods use <code>instanceof</code> in the determination of whether two objects are equal. This is fraught with peril, 1915since it is important that the equals method is symmetrical (in other words, <code>a.equals(b) == b.equals(a)</code>). 1916If B is a subtype of A, and A's equals method checks that the argument is an instanceof A, and B's equals method 1917checks that the argument is an instanceof B, it is quite likely that the equivalence relation defined by these 1918methods 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> 1953The format string placeholder is incompatible with the corresponding 1954argument. 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 1959passed instead. 1960A runtime exception will occur when 1961this 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> 1969One of the arguments is uncompatible with the corresponding format string specifier. 1970As a result, this will generate a runtime exception when executed. 1971For example, <code>String.format("%d", "1")</code> will generate an exception, since 1972the 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> 1980A method is called that expects a Java printf format string and a list of arguments. 1981However, the format string doesn't contain any format specifiers (e.g., %s) but 1982does contain message format elements (e.g., {0}). It is likely 1983that the code is supplying a MessageFormat string when a printf-style format string 1984is required. At runtime, all of the arguments will be ignored 1985and 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> 1993A format-string method with a variable number of arguments is called, 1994but more arguments are passed than are actually used by the format string. 1995This won't cause a runtime exception, but the code may be silently omitting 1996information 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> 2004The format string is syntactically invalid, 2005and a runtime exception will occur when 2006this 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> 2014Not enough arguments are passed to satisfy a placeholder in the format string. 2015A runtime exception will occur when 2016this 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> 2024The format string specifies a relative index to request that the argument for the previous format specifier 2025be reused. However, there is no previous argument. 2026For 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 2066is used in context where a hashable class is required. 2067A class that declares an equals method but inherits a hashCode() method 2068from Object is unhashable, since it doesn't fulfill the requirement that 2069equal 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, 2077and thus doesn't fulfill the requirement that equal objects have equal hashCodes. 2078An instance of this class is used in a hash data structure, making the need to 2079fix 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> 2086This code converts a 32-bit int value to a 64-bit long value, and then 2087passes that value for a method parameter that requires an absolute time value. 2088An absolute time value is the number 2089of milliseconds since the standard base time known as "the epoch", namely January 1, 1970, 00:00:00 GMT. 2090For example, the following method, intended to convert seconds since the epoc into a Date, is badly 2091broken:</p> 2092<pre> 2093Date 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. 2096When a 32-bit value is converted to 64-bits and used to express an absolute time 2097value, 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 2103Date getDate(int seconds) { return new Date(seconds * 1000L); } 2104 2105// better, works for all dates 2106Date 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> 2114This code converts an integral value (e.g., int or long) 2115to a double precision 2116floating point number and then 2117passing the result to the Math.ceil() function, which rounds a double to 2118the next higher integer value. This operation should always be a no-op, 2119since the converting an integer to a double should give a number with no fractional part. 2120It is likely that the operation that generated the value to be passed 2121to Math.ceil was intended to be performed using double precision 2122floating 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> 2131This code converts an int value to a float precision 2132floating point number and then 2133passing the result to the Math.round() function, which returns the int/long closest 2134to the argument. This operation should always be a no-op, 2135since the converting an integer to a float should give a number with no fractional part. 2136It is likely that the operation that generated the value to be passed 2137to Math.round was intended to be performed using 2138floating 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 2147just result in exceptions being thrown. 2148Thus, if this exception occurs in a thread other than the thread that invokes 2149the test method, the exception will terminate the thread but not result 2150in 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. 2158However, the suite method needs to be declared as either</p> 2159<pre>public static junit.framework.Test suite()</pre> 2160or 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 2174super.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 2188super.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 2195set 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 2203throwing 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 2210an 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> 2217The code multiplies the result of an integer remaining by an integer constant. 2218Be sure you don't have your operator precedence confused. For example 2219i % 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 2227the range of values that can be represented as an int value. 2228This 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 2243a signed byte with a value outside that range is vacuous and likely to be incorrect. 2244To convert a signed byte <code>b</code> to an unsigned value in the range 0..255, 2245use <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> 2271The initial value of this parameter is ignored, and the parameter 2272is overwritten here. This often indicates a mistaken belief that 2273the write to the parameter will be conveyed back to 2274the 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 2282instance field in a superclass. This is confusing, and 2283may indicate an error if methods update or access one of 2284the 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 2291in this class or a superclass. This may cause the method to 2292read an uninitialized value from the field, leave the field uninitialized, 2293or 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. 2307This will lead to a <code>NullPointerException</code> when the code is executed. 2308Note that because FindBugs currently does not prune infeasible exception paths, 2309this may be a false warning.</p> 2310 2311<p> Also note that FindBugs considers the default case of a switch statement to 2312be 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, 2329a null pointer exception will occur. But the big risk here you never close 2330something 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> 2392This instanceof test will always return false, since the value being checked is guaranteed to be null. 2393Although this is safe, make sure it isn't 2394an 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 2402a null value will be dereferenced, which 2403would generate a <code>NullPointerException</code> when the code is executed. 2404Of course, the problem might be that the branch or statement is infeasible and that 2405the 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 2413dereferenced here. This may lead to a <code>NullPointerException</code> 2414when the code is executed. 2415Note that because FindBugs currently does not prune infeasible exception paths, 2416this may be a false warning.</p> 2417 2418<p> Also note that FindBugs considers the default case of a switch statement to 2419be 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. 2466Unless the field is initialized via some mechanism not seen by the analysis, 2467dereferencing 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 2475not override the <code>equals(Object)</code> method in <code>java.lang.Object</code>, 2476which 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. 2509This is very confusing because if the capitalization were 2510identical 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 2518the type of the corresponding parameter in the superclass. For example, if you have:</p> 2519 2520<blockquote> 2521<pre> 2522import alpha.Foo; 2523public class A { 2524 public int f(Foo x) { return 17; } 2525} 2526---- 2527import beta.Foo; 2528public 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 2535override the 2536<code>f(Foo)</code> method defined in class <code>A</code>, because the argument 2537types 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, 2555where the correct way to compare instances of this type is generally 2556with the equals() method. 2557It is possible to create distinct instances that are equal but do not compare as == since 2558they are different objects. 2559Examples of classes which should generally 2560not 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 2567be null because it was previously dereferenced and if it were null a null pointer 2568exception would have occurred at the earlier dereference. 2569Essentially, this code and the previous dereference 2570disagree as to whether this value is allowed to be null. Either the check is redundant 2571or 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> 2578The code here uses a regular expression that is invalid according to the syntax 2579for regular expressions. This statement will throw a PatternSyntaxException when 2580executed. 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> 2588The code here uses <code>File.separator</code> 2589where a regular expression is required. This will fail on Windows 2590platforms, where the <code>File.separator</code> is a backslash, which is interpreted in a 2591regular 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> 2602A String function is being invoked and "." or "|" is being passed 2603to a parameter that takes a regular expression as an argument. Is this what you intended? 2604For 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 2616want 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 2624the absolute value of that hashcode. If the hashcode 2625is <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, 2629including "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 2637the absolute value of that random integer. If the number returned by the random number 2638generator 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, 2647such as 1 or -1. When invoking these methods, you should only check the sign of the result, not for any specific 2648non-zero value. While many or most compareTo and compare methods only return -1, 0 or 1, some of them 2649will 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, 2656something like </p> 2657<blockquote> 2658<pre> 2659if (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> 2666if (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 2676cause of this warning is to invoke a method on an immutable object, 2677thinking that it updates the object. For example, in the following code 2678fragment,</p> 2679<blockquote> 2680<pre> 2681String dateString = getHeaderField(name); 2682dateString.trim(); 2683</pre> 2684</blockquote> 2685<p>the programmer seems to be thinking that the trim() method will update 2686the String referenced by dateString. But since Strings are immutable, the trim() 2687function returns a new String value, which is being ignored here. The code 2688should be corrected to: </p> 2689<blockquote> 2690<pre> 2691String dateString = getHeaderField(name); 2692dateString = 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 2724a 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 2732reference to the same field (e.g., x&x or x-x). Because of the nature 2733of the computation, this operation doesn't seem to make sense, 2734and may indicate a typo or 2735a 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 2743is a field with an identical name. 2744assignment 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 2758a 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 2766reference to the same variable (e.g., x&x or x-x). Because of the nature 2767of the computation, this operation doesn't seem to make sense, 2768and may indicate a typo or 2769a 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 2807is 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 2814parameter 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 2821field 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> 2828This method invokes the Thread.currentThread() call, just to call the interrupted() method. As interrupted() is a 2829static 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> 2837This method invokes the Thread.interrupted() method on a Thread object that appears to be a Thread object that is 2838not the current thread. As the interrupted() method is static, the interrupted method will be called on a different 2839object 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 2855mechanism, 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> 2882public @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> 2911public 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 2978a method in a superclass. Since methods in other classes cannot directly invoke methods 2979declared in an anonymous class, it seems that this method is uncallable. The method 2980might simply be dead code, but it is also possible that the method is intended to 2981override a method declared in a superclass, and due to an typo or other error the method does not, 2982in 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 } 3007class 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, 3017the constructor for the <code>A</code> class is invoked 3018<em>before</em> the constructor for <code>B</code> sets <code>value</code>. 3019Thus, when the constructor for <code>A</code> invokes <code>getValue</code>, 3020an 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> 3028The code invokes toString on an (anonymous) array. Calling toString on an array generates a fairly useless result 3029such as [C@16f0472. Consider using Arrays.toString to convert the array into a readable 3030String 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> 3038The code invokes toString on an array, which will generate a fairly useless result 3039such as [C@16f0472. Consider using Arrays.toString to convert the array into a readable 3040String 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> 3048One of the arguments being formatted with a format string is an array. This will be formatted 3049using a fairly useless format, such as [I@304282, which doesn't actually show the contents 3050of the array. 3051Consider 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 3059all reads of the field will return null. 3060Check 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 3067value. 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> 3074This code passes a primitive array to a function that takes a variable number of object arguments. 3075This 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, 3089consider: 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 3099escape the method), so if you have a garbage collection cycle just 3100after 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@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@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 3327defined 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> 3351This static field public but not final, and 3352could 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> 3362This static field public but not final, and 3363could be changed by malicious code or 3364by accident from another package. 3365The field could be made final to avoid 3366this vulnerability. However, the static initializer contains more than one write 3367to 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> 3394private 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 3405and 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> 3414private static Integer count = 0; 3415... 3416 synchronized(count) { 3417 count++; 3418 } 3419... 3420</pre> 3421<p>Since Integer objects can be cached and shared, 3422this code could be synchronizing on the same object as other, unrelated code, leading to unresponsiveness 3423and 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> 3432private 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 3438is locking on something that other code might also be locking. This could result in very strange and hard to diagnose 3439blocking 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, 3448such as an Integer.</p> 3449<pre> 3450private 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> 3459private static final Object fileLock = new Object(); 3460</pre> 3461<p> 3462The existing code might be OK, but it is confusing and a 3463future refactoring, such as the "Remove Boxing" refactoring in IntelliJ, 3464might replace this with the use of an interned Integer object shared 3465throughout 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> 3493synchronized() {} 3494</pre> 3495<p>Empty synchronized blocks are far more subtle and hard to use correctly 3496than most people recognize, and empty synchronized blocks 3497are almost never a better solution 3498than 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, 3536but 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 3543java.util.concurrent.locks.Lock. Such an object is locked/unlocked 3544using 3545<code>acquire()</code>/<code>release()</code> rather 3546than 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 3554a class from the java.util.concurrent package (or its subclasses). Instances 3555of these classes have their own concurrency control mechanisms that are orthogonal to 3556the synchronization provided by the Java keyword <code>synchronized</code>. For example, 3557synchronizing on an <code>AtomicBoolean</code> will not prevent other threads 3558from modifying the <code>AtomicBoolean</code>.</p> 3559<p>Such code may be correct, but should be carefully reviewed and documented, 3560and 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> 3571on 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). 3575This probably isn't what you want, and even if you do want it, you should consider changing 3576your 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. 3584Because the compiler or processor may reorder instructions, 3585threads are not guaranteed to see a completely initialized object, 3586<em>if the method can be called by multiple threads</em>. 3587You can make the field volatile to correct the problem. 3588For 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. 3597After the field is set, the object stored into that location is further updated or accessed. 3598The setting of the field is visible to other threads as soon as it is set. If the 3599futher accesses in the method that set the field serve to initialize the object, then 3600you have a <em>very serious</em> multithreading bug, unless something else prevents 3601any 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 3604threads, it might be better to not set the static field until the value 3605you 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 3612to guard against simultaneous updates to that field. But guarding a field 3613gets a lock on the referenced object, not on the field. This may not 3614provide the mutual exclusion you need, and other threads might 3615be obtaining locks on the referenced objects (for other purposes). An example 3616of this pattern would be:</p> 3617<pre> 3618private Long myNtfSeqNbrCounter = new Long(0); 3619private 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 3636threads 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 3643the class as a Singleton), 3644and will 3645have multiple threads invoke methods on that instance to service multiple 3646simultaneous requests. 3647Thus, 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 3654on the object. Calling notify() or notifyAll() without a lock held will result in 3655an <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 3662on the object. Calling wait() without a lock held will result in 3663an <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. 3685If it is null and then synchronized on a NullPointerException will be 3686thrown and the check would be pointless. Better to synchronize on 3687another 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. 3753The detector has found a call to an instance of Calendar that has been obtained via a static 3754field. 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> 3756and <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. 3763The detector has found a call to an instance of DateFormat that has been obtained via a static 3764field. 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> 3766and <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. 3773Sharing a single instance across thread boundaries without proper synchronization will result in erratic behavior of the 3774application. Under 1.4 problems seem to surface less often than under Java 5 where you will probably see 3775random 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> 3779and <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. 3786Sharing a single instance across thread boundaries without proper synchronization will result in erratic behavior of the 3787application.</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> 3791and <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 3815This 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, 3833but does not release it on all paths out of the method. In general, the correct idiom 3834for 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, 3851but does not release it on all exception paths out of the method. In general, the correct idiom 3852for 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 3879atomic. If more than one thread is incrementing the field at the same time, 3880increments 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 3888you want. With a volatile reference to an array, reads and writes of 3889the reference to the array are treated as volatile, but the array elements 3890are non-volatile. To get volatile array elements, you will need to use 3891one of the atomic array classes in java.util.concurrent (provided 3892in 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 3956to 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 4036method of URL perform domain name resolution, this can result in a big performance hit. 4037See <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. 4038Consider 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 4046method of URL perform domain name resolution, this can result in a big performance hit. 4047See <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. 4048Consider 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> 4084using <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 4087value 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 4125that 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 4135in a zero-length prototype array argument. It is more efficient to use 4136<code>myCollection.toArray(new Foo[myCollection.size()])</code> 4137If the array passed in is big enough to store all of the 4138elements of the collection, then it is populated and returned 4139directly. 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. 4147In 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 4153a 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 4191classes cannot be marked as static, doing this will require refactoring 4192the 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 4200inner 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 4222result in this case, can be determined statically, and is faster and sometimes more accurate to 4223just 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 4305possible that the method will be invoked through reflection, 4306it is more likely that the method is never used, and should be 4307removed. 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 4327a keySet iterator. It is more efficient to use an iterator on the entrySet of the map, to avoid the 4328Map.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 4352vulnerability. See <a href="http://en.wikipedia.org/wiki/HTTP_response_splitting">http://en.wikipedia.org/wiki/HTTP_response_splitting</a> 4353for more information.</p> 4354<p>FindBugs looks only for the most blatant, obvious cases of HTTP response splitting. 4355If FindBugs found <em>any</em>, you <em>almost certainly</em> have more 4356vulnerabilities that FindBugs doesn't report. If you are concerned about HTTP response splitting, you should seriously 4357consider 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 4366vulnerability. See <a href="http://en.wikipedia.org/wiki/HTTP_response_splitting">http://en.wikipedia.org/wiki/HTTP_response_splitting</a> 4367for more information.</p> 4368<p>FindBugs looks only for the most blatant, obvious cases of HTTP response splitting. 4369If FindBugs found <em>any</em>, you <em>almost certainly</em> have more 4370vulnerabilities that FindBugs doesn't report. If you are concerned about HTTP response splitting, you should seriously 4371consider 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, 4380but 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 4382See <a href="http://cwe.mitre.org/data/definitions/36.html">http://cwe.mitre.org/data/definitions/36.html</a> 4383for more information.</p> 4384<p>FindBugs looks only for the most blatant, obvious cases of absolute path traversal. 4385If FindBugs found <em>any</em>, you <em>almost certainly</em> have more 4386vulnerabilities that FindBugs doesn't report. If you are concerned about absolute path traversal, you should seriously 4387consider 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 4397See <a href="http://cwe.mitre.org/data/definitions/23.html">http://cwe.mitre.org/data/definitions/23.html</a> 4398for more information.</p> 4399<p>FindBugs looks only for the most blatant, obvious cases of relative path traversal. 4400If FindBugs found <em>any</em>, you <em>almost certainly</em> have more 4401vulnerabilities that FindBugs doesn't report. If you are concerned about relative path traversal, you should seriously 4402consider 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 4411to be dynamically generated. Consider using 4412a prepared statement instead. It is more efficient and less vulnerable to 4413SQL 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. 4421If unchecked, tainted data from a user is used in building this String, SQL injection could 4422be 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 4430vulnerability. See <a href="http://en.wikipedia.org/wiki/Cross-site_scripting">http://en.wikipedia.org/wiki/Cross-site_scripting</a> 4431for more information.</p> 4432<p>FindBugs looks only for the most blatant, obvious cases of cross site scripting. 4433If FindBugs found <em>any</em>, you <em>almost certainly</em> have more cross site scripting 4434vulnerabilities that FindBugs doesn't report. If you are concerned about cross site scripting, you should seriously 4435consider 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 4443for a reflected cross site scripting 4444vulnerability. See <a href="http://en.wikipedia.org/wiki/Cross-site_scripting">http://en.wikipedia.org/wiki/Cross-site_scripting</a> 4445for more information.</p> 4446<p>FindBugs looks only for the most blatant, obvious cases of cross site scripting. 4447If FindBugs found <em>any</em>, you <em>almost certainly</em> have more cross site scripting 4448vulnerabilities that FindBugs doesn't report. If you are concerned about cross site scripting, you should seriously 4449consider 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 4458vulnerability. See <a href="http://en.wikipedia.org/wiki/Cross-site_scripting">http://en.wikipedia.org/wiki/Cross-site_scripting</a> 4459for more information.</p> 4460<p>FindBugs looks only for the most blatant, obvious cases of cross site scripting. 4461If FindBugs found <em>any</em>, you <em>almost certainly</em> have more cross site scripting 4462vulnerabilities that FindBugs doesn't report. If you are concerned about cross site scripting, you should seriously 4463consider 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> 4472This code casts a Collection to an abstract collection 4473(such as <code>List</code>, <code>Set</code>, or <code>Map</code>). 4474Ensure that you are guaranteed that the object is of the type 4475you are casting to. If all you need is to be able 4476to 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> 4484This code casts an abstract collection (such as a Collection, List, or Set) 4485to a specific concrete implementation (such as an ArrayList or HashSet). 4486This might not be correct, and it may make your code fragile, since 4487it makes it harder to switch to other concrete implementations at a future 4488point. Unless you have a particular reason to do so, just use the abstract 4489collection 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> 4497This cast is unchecked, and not all instances of the type casted from can be cast to 4498the type it is being cast to. Check that your program logic ensures that this 4499cast 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> 4507This code performs an unchecked cast of the return value of a method. 4508The code might be calling the method in such a way that the cast is guaranteed to be 4509safe, but FindBugs is unable to verify that the cast is safe. Check that your program logic ensures that this 4510cast 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> 4518This instanceof test will always return true (unless the value being tested is null). 4519Although this is safe, make sure it isn't 4520an indication of some misunderstanding or some other logic error. 4521If you really want to test the value for being null, perhaps it would be clearer to do 4522better 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> 4530The code performs an unsigned right shift, whose result is then 4531cast to a short or byte, which discards the upper bits of the result. 4532Since the upper bits are discarded, there may be no difference between 4533a 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> 4571This instruction assigns a value to a local variable, 4572but the value is not read or used in any subsequent instruction. 4573Often, this indicates an error, because the value computed is never 4574used. 4575</p> 4576<p> 4577Note that Sun's javac compiler often generates dead stores for 4578final local variables. Because FindBugs is a bytecode-based tool, 4579there 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> 4587This statement assigns to a local variable in a return statement. This assignment 4588has 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 4596read. This store may have been introduced to assist the garbage collector, but 4597as 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> 4605This instruction assigns a value to a local variable, 4606but the value is not read or used in any subsequent instruction. 4607Often, this indicates an error, because the value computed is never 4608used. There is a field with the same name as the local variable. Did you 4609mean 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> 4625This code seems to be passing a non-serializable object to the ObjectOutput.writeObject method. 4626If 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> 4634This 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 4642a Runnable is expected. This is rather unusual, and may indicate a logic error 4643or 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 4651define an equals method itself. Thus, equality on instances of this class will 4652ignore the identity of the subclass and the added fields. Be sure this is what is intended, 4653and that you don't need to override the equals method. Even if you don't need to override 4654the equals method, consider overriding it anyway to document the fact 4655that the equals method for the subclass just return the result of 4656invoking 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 4664is compatible with the type of the <code>this</code> object. There might not be anything wrong with 4665this 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> 4689An argument not of type Boolean is being formatted with a %b format specifier. This won't throw an 4690exception; instead, it will print true for any nonnull value, and false for null. 4691This 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> 4699An inner class is invoking a method that could be resolved to either a inherited method or a method defined in an outer class. 4700For example, you invoke <code>foo(17)</code>, which is defined in both a superclass and in an outer method. 4701By the Java semantics, 4702it will be resolved to invoke the inherited method, but this may not be want 4703you intend. 4704</p> 4705<p>If you really intend to invoke the inherited method, 4706invoke it by invoking the method on super (e.g., invoke super.foo(17)), and 4707thus it will be clear to other readers of your code and to FindBugs 4708that 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 4711classfiles, it 4712can't tell the difference between an invocation of <code>this.foo(17)</code> and <code>foo(17)</code>, it will still 4713complain 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> 4729This code casts the result of an integral division (e.g., int or long division) 4730operation to double or 4731float. 4732Doing division on integers truncates the result 4733to the integer value closest to zero. The fact that the result 4734was cast to double suggests that this precision should have been retained. 4735What was probably meant was to cast one or both of the operands to 4736double <em>before</em> performing the division. Here is an example: 4737</p> 4738<blockquote> 4739<pre> 4740int x = 2; 4741int y = 5; 4742// Wrong: yields result 0.0 4743double value1 = x / y; 4744 4745// Right: yields result 0.4 4746double 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> 4755This code performs integer multiply and then converts the result to a long, 4756as in:</p> 4757<pre> 4758 long convertDaysToMilliseconds(int days) { return 1000*3600*24*days; } 4759</pre> 4760<p> 4761If the multiplication is done using long arithmetic, you can avoid 4762the possibility that the result will overflow. For example, you 4763could fix the above code to:</p> 4764<pre> 4765 long convertDaysToMilliseconds(int days) { return 1000L*3600*24*days; } 4766</pre> 4767or 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, 4778and then uses the result as the index of an array. 4779If the values being averaged are very large, this can overflow (resulting in the computation 4780of a negative average). Assuming that the result is intended to be nonnegative, you 4781can use an unsigned right shift instead. In other words, rather that using <code>(low+high)/2</code>, 4782use <code>(low+high) >>> 1</code> 4783</p> 4784<p>This bug exists in many earlier implementations of binary search and merge sort. 4785Martin Buchholz <a href="http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6412541">found and fixed it</a> 4786in the JDK libraries, and Joshua Bloch 4787<a href="http://googleresearch.blogspot.com/2006/06/extra-extra-read-all-about-it-nearly.html">widely 4788publicized 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> 4796The code uses x % 2 == 1 to check to see if a value is odd, but this won't work 4797for negative numbers (e.g., (-5) % 2 == -1). If this code is intending to check 4798for 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. 4806Did 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 4823the 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 4854to 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 4862to 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 4871intended to refer to a different variable, or perhaps the earlier check to see if the 4872variable 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, 4897and the return value of that method is one that should generally be checked 4898for 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 4906a null value will be dereferenced, which 4907would generate a <code>NullPointerException</code> when the code is executed. 4908Of course, the problem might be that the branch or statement is infeasible and that 4909the null pointer exception can't ever be executed; deciding that is beyond the ability of FindBugs. 4910Due to the fact that this value had been previously tested for nullness, 4911this 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, 4919but the parameter is explicitly annotated as being Nullable. Either the use 4920of 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 4928field that does not seem to ever have a non-null value written to it. 4929Unless the field is initialized via some mechanism not seen by the analysis, 4930dereferencing 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., & 4938or |) 4939rather than short-circuit logic (&& or ||). In addition, 4940it seem possible that, depending on the value of the left hand side, you might not 4941want to evaluate the right hand side (because it would have side effects, could cause an exception 4942or could be expensive.</p> 4943<p> 4944Non-short-circuit logic causes both sides of the expression 4945to be evaluated even when the result can be inferred from 4946knowing the left-hand side. This can be less efficient and 4947can result in errors if the left-hand side guards cases 4948when 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 4952Language 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., & 4961or |) 4962rather than short-circuit logic (&& or ||). 4963Non-short-circuit logic causes both sides of the expression 4964to be evaluated even when the result can be inferred from 4965knowing the left-hand side. This can be less efficient and 4966can result in errors if the left-hand side guards cases 4967when 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 4970Language 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 4979return a length zero array rather than a null reference to indicate that there 4980are no results (i.e., an empty list of results). 4981This 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. 4985For example, <code>File.listFiles()</code> returns an empty list 4986if given a directory containing no files, and returns null if the file 4987is 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 5003known 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 5010both 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 5017the 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 5024the 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 5074value is non-null. In almost all situations, if the result is non-null, you will want 5075to 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 5082the remainder of that value modulo another value. Since the hashCode 5083can be negative, the result of the remainder operation 5084can also be negative. </p> 5085<p> Assuming you want to ensure that the result of your computation is nonnegative, 5086you may need to change your code. 5087If you know the divisor is a power of 2, 5088you can use a bitwise and operator instead (i.e., instead of 5089using <code>x.hashCode()%n</code>, use <code>x.hashCode()&(n-1)</code>. 5090This is probably faster than computing the remainder as well. 5091If you don't know that the divisor is a power of 2, take the absolute 5092value 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 5101the remainder of that value modulo another value. Since the random 5102number can be negative, the result of the remainder operation 5103can also be negative. Be sure this is intended, and strongly 5104consider 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 5112is the same type as the type the method is invoked on, and from our analysis it looks 5113like the return value might be important (e.g., like ignoring the 5114return 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 5117a simple analysis of the body of the method. You can use a @CheckReturnValue annotation 5118to instruct FindBugs as to whether ignoring the return value of this method 5119is 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> 5164Such 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 5181the 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 5188correct if multiple instances are being manipulated, 5189and 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. 5197This 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 5205has absolutely no effect. 5206This may be leftover marking from a previous version of the code in which the class was transient, or 5207it 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 5235control flow continues onto the same place regardless of whether or not 5236the branch is taken. For example, 5237this is caused by having an empty statement 5238block 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 5250flow follows to the same or following line regardless of whether or not 5251the branch is taken. 5252Often, this is caused by inadvertently using an empty statement as the 5253body 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. 5264The 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, 5266consider 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. 5273The 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, 5275consider 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 5282the object is constructed. Elsewhere, it is loaded and dereferenced without a null check. 5283This could be a either an error or a questionable design, since 5284it means a null pointer exception will be generated if that field is dereferenced 5285before 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 5293value. 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 5318document.write( "Last updated "+ document.lastModified + "." ); 5319//end hiding contents ---> 5320</script> 5321<p> Send comments to <a class="sidebar" href="mailto:findbugs@cs.umd.edu">findbugs@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
