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