Default FindBugs plugin

This plugin contains all of the standard FindBugs detectors.

]]>

Correctness C

Probable bug - an apparent coding mistake resulting in code that was probably not what the developer intended. We strive for a low false positive rate.

Security S

A use of untrusted input in a way that could create a remotely exploitable security vulnerability.

Bad practice B

Violations of recommended and essential coding practice. Examples include hash code and equals problems, cloneable idiom, dropped exceptions, Serializable problems, and misuse of finalize. We strive to make this analysis accurate, although some groups may not care about some of the bad practices.

Dodgy D

code that is confusing, anomalous, or written in a way that leads itself to errors. Examples include dead local stores, switch fall through, unconfirmed casts, and redundant null check of value known to be null. More false positives accepted. In previous versions of FindBugs, this category was known as Style.

Performance P

code that is not necessarily incorrect but may be inefficient

Malicious code vulnerability V

code that is vulnerable to attacks from untrusted code

Multithreaded correctness M

code flaws having to do with threads, locks, and volatiles

Internationalization I

code flaws having to do with internationalization and locale

This detector looks for synchronization on a shared builtin constant (such as a String).

]]>

This detector looks for a field that is synchronized on and then null checked.

]]>

Looks for violations of the rules for classes annotated as net.jcip.annotations.Immutable.

]]>

Looks for problems with arising from Java 1.5 var args.

]]>

Record annotations from the net.jcip.annotations package.

]]>

Note the type qualifiers relevant to analyzing a method.

]]>

Suppresses warnings based on use of the edu.umd.cs.findbugs.annotations.NoteSuppressWarnings annotation.

]]>

Records annotation retention.

]]>

Records synthetic classes, methods, fields, etc.

]]>

Builds of database of all methods defined in analyzed classes, for use by other detectors.

]]>

Try to determine which classes have constant references to their .class objects.

]]>

Builds of database of all methods invoked in analyzed classes, for use by other detectors.

]]>

Looks for potential confusion between inherited and outer methods.

]]>

Looks for annotations to check return values of a method.

]]>

Looks for annotations to check return values of a method.

]]>

Look for code that synchronizes on the results of getClass rather than on class literals.

]]>

This detector produces summary information for what is stored into fields.

]]>

Looks for @NonNull annotations on methods, fields, and parameters. These can be used by the FindNullDeref detector to generate warnings when a possibly-null value is used in a context where only non-null values should be used.

]]>

Analyze all methods in the application to determine which dereference parameters unconditionally. This information is used in a later analysis pass to find call sites where null values may be passed to those methods.

This is a slow detector.

]]>

Analyze all methods in the application to determine which methods always return nonnull values.

]]>

Looks for methods with Boolean return type that return explicit null values.

]]>

Looks for cases where the return value of a function is discarded after being checked for non-null.

]]>

Looks for uses of this.getClass().getResource(...), which can give unexpected results if the class is extended by a class in another package. /p> ]]>

Looks for an infinite recursive loop.

]]>

Looks for an infinite loop.

]]>

Looks for an infinite recursive loop. It is a slow detector.

]]>

Looks for bug patterns in the usage of volatile fields.

]]>

This looks for creation of empty zip file entries. It is a moderately fast detector.

]]>

This detector looks for anonymous inner classes that define methods that are probably intended to but do not override methods in a superclass.

]]>

Checks that fields and methods don't use the name assert or enum as they are keywords in Java 5.

]]>

The equals and hashCode method on java.net.URL resolve the domain name. As a result, these operations can be very expensive, and this detector looks for places where those methods might be invoked.

]]>

This detector looks for finalizers that null out fields of a class. This does not help the garbage collector in any way, the nulling out of fields has no effect.

]]>

This detector looks for obvious/blatent cases of cross site scripting vulnerabilities.

]]>

This detector is just a hook for testing new detectors. Normally, this detector does nothing.

]]>

This detector looks for string constants that are duplicated across multiple classfiles.

]]>

Look for code that should be executed inside doPrivileged blocks.

]]>

Checks that all references call be resolved.

]]>

This detector looks for switch statements containing fall through.

]]>

This detector looks for places where a field is assigned by reading the value of the same field.

]]>

This detector looks for places where a value is compared with itself.

]]>

This detector looks for places where a value is compared with itself.

]]>

This detector looks for suspicious uses of non-short-circuiting boolean operators (| and & instead of || and &&).

]]>

This detector looks for try-catch blocks that catch an IllegalMonitorStateException.

]]>

This detector looks for uses of floating point math. It is a moderately fast detector.

]]>

This detector looks for violations of the idioms for writing cloneable classes.

]]>

This detector looks for violations of the idioms for writing classes that implement Comparator.

]]>

This detector looks for code where an exception is caught, but nothing is done to handle the exception.

]]>

Looks for loads of values known to be null.

]]>

This detector looks for bad arguments being passed to methods (e.g., substring(0)).

]]>

This detector looks for calls to pointless methods, such as the no-argument String constructor.

]]>

Looks for calls to Number constructors with primitive arguments. /p> ]]>

This detector looks for instances of double checked locking.

]]>

This detector looks for calls to finalize() and other finalizer-related issues.

]]>

This detector looks for problems in the definition of the hashCode() and equals() methods.

]]>

Looks for equals methods that override equals methods in a superclass where the equivalence relationship might not be symmetrical.

]]>

This detector looks for calls to notify() that don't seem to modify mutable object state.

]]>

This detector looks for methods that return mutable static data.

]]>

This detector looks for calls to Thread.run(). It is a fast detector.

]]>

This detector looks for loops that spin reading from a field.

]]>

This detector looks for calls to wait() with two (or more) locks held. It is a slow detector.

]]>

This detector looks for calls to wait() not in a conditional or loop.

]]>

This detector looks for reads of uninitialized fields in constructors.

]]>

This detector looks for get and set methods where the get is unsynchronized while the set is synchronized.

]]>

This detector looks for potentially circular class initialization dependencies.

]]>

This iterator looks for problems in how Iterator classes are defined.

]]>

This detector looks for fields that are accessed in an inconsistent manner with respect to locking.

]]>

This detector looks for comparisons of String objects using the == or != operators.

]]>

This detector looks for synchronization on objects read from modified fields.

]]>

This detector looks for code that seems to be synchronizing on a field in order to guard updates of that field.

]]>

This detector looks for static fields that may be modified by malicious code.

]]>

This detector looks for suspiciously-named methods.

]]>

This detector looks for calls to InputStream.read() or InputStream.skip() where the return value is ignored.

]]>

This detector looks for potential problems in the implementation of Serializable classes.

]]>

This detector looks for constructors that start threads.

]]>

This detector looks for incorrect for loops.

]]>

This detector looks for fields whose value is never read.

]]>

This detector looks for calls to wait() that are not in a loop.

]]>

This detector looks for calls to methods where the return value is suspiciously ignored. It is a slow detector.

]]>

This detector looks for places where a null pointer exception might occur. It also looks for redundant comparisons of reference values against null. It is a slow detector.

]]>

This detector looks for IO stream objects which do not escape the method and do not appear to be closed on all paths out of the method. It is a slow detector.

]]>

This detector looks for methods that return either arrays or an explicit null reference. Returning a zero length array is generally preferred in this context to returning a null reference.

]]>

This detector looks for control flow statements which have no effect.

]]>

This detector looks for JSR-166 (java.util.concurrent) locks which are acquired, but not released on all paths out of the method. It is a moderately fast detector. Note that in order to use this detector, you need to have the java.util.concurrent package in the auxiliary classpath (or be analyzing the package itself).

]]>

This detector looks for places where two reference values are compared with the == or != operator, and the class is of a type (such as java.lang.String) where comparing reference values is generally an error. It is a slow detector.

]]>

This detector looks for calls to wait(), notify(), or notifyAll() which do not appear to be made on an object which is currently locked. It is a moderately fast detector. This detector is disabled because it is still under development, and produces too many false positives.

]]>

This detector looks for empty synchronized blocks.

]]>

This detector looks for fields that are accessed in an inconsistent manner with respect to locking. It is a slow detector.

]]>

This detector looks for self assignments of local variables.

]]>

This detector looks for suspicious bitwise logical expressions.

]]>

This detector looks for lazy field initialization where the field is not volatile. It is a moderately fast detector.

]]>

This detector looks for ordinary synchronization performed on JSR166 locks. It is a moderately fast detector.

]]>

This detector looks for private methods that are never called.

]]>

This detector looks for String concatenation in loops using +.

]]>

This detector looks for code that converts Collections to arrays using the toArray() method that takes a prototype array, passing an array argument which is zero-length.

]]>

This detector looks for JUnit tests that are malformed.

]]>

This detector looks for code that extends an Adapter class and overrides a Listener method with the wrong signature.

]]>

This detector looks for calls to getXXX or setXXX methods of a result set where the field index is 0. As ResultSet fields start at index 1, this is always a mistake.

]]>

This detector looks for type checks using the instanceof operator where the determination can be done statically.

]]>

This detector looks for Applet constructors that call methods in the parent Applet that rely on the Applet stub. Since this stub isn't initialized until just before the init() method, these methods will fail in the constructor.

]]>

This detector looks calls to equals(java.lang.Object) on arrays, or final classes that do not override the equals method in the Object class. This means that equals semantics is the same as ==, and probably a mistake.

]]>

This detector looks for calls to Thread.interrupted() from a non static context. If it is called from Thread.currentThread().interrupted(), then it is just a useless exercise, just use Thread.interrupted(). However if it is called on an arbitrary thread object, it is most probably an error, as interrupted() is always called on the current thread.

]]>

This detector uses data flow analysis to look for invocations of execute methods on SQL statements in switch something other than a constant string is passed as an argument.

]]>

This detector looks for assignments to local variables that are never subsequently read. It is a moderately fast detector.

]]>

This detector looks for class level fields that are masked by local fields defined in methods.

]]>

This detector looks for accessing the value of a Map entry, using a key that was retrieved from a keySet iterator.

]]>

This detector looks for code that creates objects based on classes that only define static methods.

]]>

This detector looks for catch clauses that catch Exception, when no code in the block throws Exception.

]]>

Looks for floating point equality expressions. A fast detector.

]]>

This detector looks for I/O streams and database resources that are not cleaned up on all paths out of a method. This is a slow detector.

]]>

This detector looks for code that calls java.lang.Math static methods on constant values, where the resultant value is a statically known constant. It is faster, and sometimes more accurate, to use the constant instead.

]]>

This detector looks circular dependencies among classes.

]]>

This detector looks for classes that declare they implement the same interface as a super class. This is redundant, if a superclass implements an interface, so does the subclass.

]]>

This detector looks for potential problems in implementing the Struts framework.

]]>

This detector looks for public classes that synchronize and use wait(), notify() or notifyAll() on this. This exposes a synchronization implementation as a public artifact of the class. Clients of the class may use an instance of the class as it's own synchronizing object, and cause havoc to the base implementation.

]]>

This detector looks for calls to methods where the return value is suspiciously ignored.

]]>

This detector looks for places where the result of integer division is cast to double. Often, what was meant was to cast the integer operands to double and then perform the division.

]]>

This detector looks for bad casts of object references.

]]>

This detector looks for bad casts of object references using data flow analysis.

]]>

This detector looks for stores of non Serializable objects into Http sessions.

]]>

This detector looks for stores of non Serializable objects passed to the writeObject method of an ObjectOutput.

]]>

This detector looks for regular expressions that have invalid syntax.

]]>

This detector problems looks for miscellaneous small errors mentioned by Joshua Bloch and Neal Gafter in their work on Programming Puzzlers.

]]>

This detector looks for calls to Thread.sleep() made with a lock held. It is a slow detector.

]]>

This detector looks for if/else or switch statements that have the same code for two branches, thus rendering the test useless. This often is caused by copying and pasting the two branches, causing incorrect logic for the one branch.

]]>

This detector looks for internal classes that write to member variables of the owning class, when that member variable is private. In this case, a special compiler generated accessor method needs to be used to write to this variable. Relaxing the visibility to protected will allow the field to be directly written.

]]>

This detector looks for direct allocations of implementations of XML interfaces. This ties the code to a specific implementation, rather than using the supplied factory pattern to create these objects.

]]>

This detector looks for equals(Object) method implementations which unconditionally dereference their parameter. This violates the contract defined by java.lang.Object.equals(), which states that if the parameter is null, the method must return null.

It is a slow detector.

]]>

This detector looks for subclasses that implement methods defined in the super class, that only pass the parameters untouched to the parent class method. These methods can just be removed.

]]>

This detector for final classes that declare protected members. As this class can not be derived from, the use of protected access for members is incorrect. The access should be changed to public or private to represent the correct intention of the field. This was probably caused by a change in use for this class, without completely changing all of the class to the new paradigm.

]]>

This detector looks for simple assignments of literal boolean values to variables in conditional expressions.

]]>

TrainNullReturnValues determines which methods may return null and saves them to a file. The resulting file may be used in a subsequent pass to improve the precision of the null-dereference detector. Since this is just a training pass, no warnings are reported.

This is a slow detector.

]]>

TrainUnconditionalParamDerefs determines which methods may unconditionally dereference parameters and saves them to a file. The resulting file may be used in a subsequent pass to improve the precision of the null-dereference detector. Since this is just a training pass, no warnings are reported.

This is a slow detector.

]]>

TrainFieldStoreTypes analyzes the types stored into fields and stores them to a database. The database may be used in a later pass to make type analysis more precise.

This is a slow detector.

]]>

TrainNonNullAnnotations collects @NonNull and @PossiblyNull annotations and stores them to database files. This is a fast detector.

]]>

This detector is just for debugging method call resolution in FindBugs. Don't enable it.

]]>

This detector just collects summary statistics information about the analysis process.

]]>

This detector is a code example showing how to write a FindBugs detector using the ASM bytecode analysis framework.

]]>

This detector looks at the arguments of calls to generic container methods that receive a java.lang.Object to see if the argument's type is related to the container's parameter. Arguments with unrelated class types are never going to be in the container. For example, if foo is a List<String> and bar is a StringBuffer, the call foo.contains(bar) will always return false. This is a fast detector.

]]>

This detector warns about static fields of type java.util.Calendar or java.text.DateFormat (and subclasses) because Calendars are inherently unsafe for multithreaded use.

]]>

This is an internal detector used only for testing dataflow analyses. It is not enabled by default.

]]>

Check for violations of properties specified by JSR-305 type qualifier annotations.

]]>

Looks for an attempt to append to an object output stream

]]>

Class too big for analysis {0} is too big for analysis

This class is bigger than can be effectively handled, and was not fully analyzed for errors.

]]>

Empty database password Empty database password in {1}

This code creates a database connect using a blank or empty password. This indicates that the database is not protected by a password.

]]>

Hardcoded constant database password Hardcoded constant database password in {1}

This code creates a database connect using a hardcoded, constant password. Anyone with access to either the source code or the compiled code can easily learn the password.

]]>

HTTP cookie formed from untrusted input HTTP cookie formed from untrusted input in {1}

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 vulnerability. See http://en.wikipedia.org/wiki/HTTP_response_splitting for more information.

FindBugs looks only for the most blatent, obvious cases of HTTP response splitting. If FindBugs found any, you almostly certainly have more vulnerabilities that FindBugs doesn't report. If you are concerned about HTTP response splitting, you should seriously consider using a commercial static analysis or pen-testing tool, such as those provided by Fortify Software, a sponsor of the FindBugs project. If your software is open source, Fortify will scan your code for free as part of the JOR (Java Open Review) effort.

]]>

HTTP Response splitting vulnerability HTTP parameter directly written to HTTP header output in {1}

This code directly writes an HTTP parameter to an HTTP header, which allows for a HTTP response splitting vulnerability. See http://en.wikipedia.org/wiki/HTTP_response_splitting for more information.

]]>

Servlet reflected cross site scripting vulnerability HTTP parameter written to Servlet output {1}

This code directly writes an HTTP parameter to Servlet output, which allows for a reflected cross site scripting vulnerability. See http://en.wikipedia.org/wiki/Cross-site_scripting for more information.

FindBugs looks only for the most blatent, obvious cases of cross site scripting. If FindBugs found any, you almostly certainly have more cross site scripting vulnerabilities that FindBugs doesn't report. If you are concerned about cross site scripting, you should seriously consider using a commercial static analysis or pen-testing tool, such as those provided by Fortify Software, a sponsor of the FindBugs project. If your software is open source, Fortify will scan your code for free as part of the JOR (Java Open Review) effort.

]]>

Servlet reflected cross site scripting vulnerability HTTP parameter written to Servlet error page in {1}

This code directly writes an HTTP parameter to a Server error page (using HttpServletResponse.sendError). Echoing this untrusted input allows for a reflected cross site scripting vulnerability. See http://en.wikipedia.org/wiki/Cross-site_scripting for more information.

]]>

JSP reflected cross site scripting vulnerability HTTP parameter directly written to JSP output, giving reflected XSS vulnerability in {1.class}

This code directly writes an HTTP parameter to JSP output, which allows for a cross site scripting vulnerability. See http://en.wikipedia.org/wiki/Cross-site_scripting for more information.

]]>

Certain swing methods needs to be invoked in Swing thread Call to swing method in {1} needs to be performed in Swing event thread

(From JDC Tech Tip): The Swing methods show(), setVisible(), and pack() will create the associated peer for the frame. With the creation of the peer, the system creates the event dispatch thread. This makes things problematic because the event dispatch thread could be notifying listeners while pack and validate are still processing. This situation could result in two threads going through the Swing component-based GUI -- it's a serious flaw that could result in deadlocks or other related threading issues. A pack call causes components to be realized. As they are being realized (that is, not necessarily visible), they could trigger listener notification on the event dispatch thread.

]]>

An apparent infinite loop There is an apparent infinite loop in {1}

This loop doesn't seem to have a way to terminate (other than by perhaps throwing an exception).

]]>

An apparent infinite recursive loop There is an apparent infinite recursive loop in {1}

This method unconditionally invokes itself. This would seem to indicate an infinite recursive loop that will result in a stack overflow.

]]>

A container is added to itself A container is added to itself in {1}

A container is added to itself. As a result, computing the hashCode of this set will throw a StackOverflowException.

]]>

A volatile reference to an array doesn't treat the array elements as volatile {1} is a volatile reference to an array; the array elements are non-volatile

This declares a volatile reference to an array, which might not be what you want. With a volatile reference to an array, reads and writes of the reference to the array are treated as volatile, but the array elements are non-volatile. To get volatile array elements, you will need to use one of the atomic array classes in java.util.concurrent (provided in Java 5.0).

]]>

Usage of GetResource may be unsafe if class is extended Usage of GetResource in {1} may be unsafe if class is extended

Calling this.getClass().getResource(...) could give results other than expected if this class is extended by a class in another package.

]]>

Method with Boolean return type returns explicit null {1} has Boolean return type and returns explicit null

A method that returns either Boolean.TRUE, Boolean.FALSE or null is an accident waiting to happen. This method can be invoked as though it returned a value of type boolean, and the compiler will insert automatic unboxing of the Boolean value. If a null value is returned, this will result in a NullPointerException.

]]>

Synchronize and null check on the same field. In {1} the field {2.givenClass} is synchronized on and then checked if null.

Since the field is synchronized on, it seems not likely to be null. If it is null and then synchronized on a NullPointerException will be thrown and the check would be pointless. Better to synchronize on another field.

]]>

Testing Test warning generated in {1}

This bug pattern is only generated by new, incompletely implemented bug detectors.

]]>

Unknown bug pattern Unknown bug pattern BUG_PATTERN in {1}

A warning was recorded, but findbugs can't find the description of this bug pattern and so can't describe it. This should occur only in cases of a bug in FindBugs or its configuration, or perhaps if an analysis was generated using a plugin, but that plugin is not currently loaded. .

]]>

Creates an empty zip file entry Empty zip file entry created in {1}

The code calls putNextEntry(), immediately followed by a call to closeEntry(). This results in an empty ZipFile entry. The contents of the entry should be written to the ZipFile between the calls to putNextEntry() and closeEntry().

]]>

Creates an empty jar file entry Empty jar file entry created in {1}

The code calls putNextEntry(), immediately followed by a call to closeEntry(). This results in an empty JarFile entry. The contents of the entry should be written to the JarFile between the calls to putNextEntry() and closeEntry().

]]>

Dubious catching of IllegalMonitorStateException Dubious catching of IllegalMonitorStateException in {1}

IllegalMonitorStateException is generally only thrown in case of a design flaw in your code (calling wait or notify on an object you do not hold a lock on).

]]>

Method performs math using floating point precision {1} performs math using floating point precision

The method performs math operations using floating point precision. Floating point precision is very imprecise. For example, 16777216.0f + 1.0f = 16777216.0f. Consider using double math instead.

]]>

Class implements Cloneable but does not define or use clone method Class {0} implements Cloneable but does not define or use clone method

Class implements Cloneable but does not define or use the clone method.

]]>

Class defines clone() but doesn't implement Cloneable {0} defines clone() but doesn't implement Cloneable

This class defines a clone() method but the class doesn't implement Cloneable. There are some situations in which this is OK (e.g., you want to control how subclasses can clone themselves), but just make sure that this is what you intended.

]]>

clone method does not call super.clone() {1} does not call super.clone()

This non-final class defines a clone() method that does not call super.clone(). If this class ("A") is extended by a subclass ("B"), and the subclass B calls super.clone(), then it is likely that B's clone() method will return an object of type A, which violates the standard contract for clone().

If all clone() methods call super.clone(), then they are guaranteed to use Object.clone(), which always returns an object of the correct type.

]]>

Use of identifier that is a keyword in later versions of Java {1} uses {2} for a variable name, which is a keyword in later versions of Java

The identifier is a word that is reserversed as a keyword in later versions of Java, and your code will need to be changed in order to compile it in later versions of Java.

]]>

Use of identifier that is a keyword in later versions of Java {1} conflicts with a keyword in a more recent version of Java

This identifier is used as a keyword in later versions of Java. This code, and any code that references this API, will need to be changed in order to compile it in later versions of Java.

]]>

Method might drop exception {1} might drop {2}

This method might drop an exception. In general, exceptions should be handled or reported in some way, or they should be thrown out of the method.

]]>

Method might ignore exception {1} might ignore {2}

This method might ignore an exception. In general, exceptions should be handled or reported in some way, or they should be thrown out of the method.

]]>

Method invoked that should be only be invoked inside a doPrivileged block {1} invokes {2}, which should be invoked from within a doPrivileged block

This code invokes a method that requires a security permission check. If this code will be granted security permissions, but might be invoked by code that does not have security permissions, then the invocation needs to occur inside a doPrivileged block.

]]>

Method invoked that should be only be invoked inside a doPrivileged block {1} invokes {2}, which should be invoked from within a doPrivileged block

]]>

Classloaders should only be created inside doPrivileged block {1} creates a {2} classloader, which should be performed within a doPrivileged block

This code creates a classloader, which requires a security manager. If this code will be granted security permissions, but might be invoked by code that does not have security permissions, then the classloader creation needs to occur inside a doPrivileged block.

]]>

Classloaders should only be created inside doPrivileged block {1} creates a {2} classloader, which should be performed within a doPrivileged block

]]>

Fields of immutable classes should be final {1.givenClass} should be final since {0} is marked as Immutable.

The class is annotated with net.jcip.annotations.Immutable, and the rules for that annotation require that all fields are final. .

]]>

Thread passed where Runnable expected Thread passed where Runnable expected in {1}

A Thread object is passed as a parameter to a method where a Runnable is expected. This is rather unusual, and may indicate a logic error or cause unexpected behavior.

]]>

Maps and sets of URLs can be performance hogs {1} is or uses a map or set of URLs, which can be a performance hog

This method or field is or uses a Map or Set of URLs. Since both the equals and hashCode method of URL perform domain name resolution, this can result in a big performance hit. See http://michaelscharf.blogspot.com/2006/11/javaneturlequals-and-hashcode-make.html for more information. Consider using java.net.URI instead.

]]>

The equals and hashCode methods of URL are blocking {1} invokes {2}, which blocks to do domain name resolution

The equals and hashCode method of URL perform domain name resolution, this can result in a big performance hit. See http://michaelscharf.blogspot.com/2006/11/javaneturlequals-and-hashcode-make.html for more information. Consider using java.net.URI instead.

]]>

Can't use reflection to check for presence of annotation with default retention {1} uses reflection to check for the presence of an annotation that has default retention

Unless an annotation has itself been annotated with a @Retention other than the default of source-only retention, the annotation isn't retained in the classfile and can't be observed using reflection (e.g., by using the isAnnotationPresent method). .

]]>

Method invokes System.exit(...) {1} invokes System.exit(...), which shuts down the entire virtual machine

Invoking System.exit shuts down the entire Java virtual machine. This should only been done when it is appropriate. Such calls make it hard or impossible for your code to be invoked by other code. Consider throwing a RuntimeException instead.

]]>

Method invokes dangerous method runFinalizersOnExit {1} invokes dangerous method runFinalizersOnExit

Never call System.runFinalizersOnExit or Runtime.runFinalizersOnExit for any reason: they are among the most dangerous methods in the Java libraries. -- Joshua Bloch

]]>

Method invokes inefficient new String(String) constructor {1} invokes inefficient new String(String) constructor

Using the java.lang.String(String) constructor wastes memory because the object so constructed will be functionally indistinguishable from the String passed as a parameter. Just use the argument String directly.

]]>

Method invokes inefficient new String() constructor {1} invokes inefficient new String() constructor

Creating a new java.lang.String object using the no-argument constructor wastes memory because the object so created will be functionally indistinguishable from the empty string constant "". Java guarantees that identical string constants will be represented by the same String object. Therefore, you should just use the empty string constant directly.

]]>

Method invokes toString() method on a String Method {1} invokes toString() method on a String

Calling String.toString() is just a redundant operation. Just use the String.

]]>

Explicit garbage collection; extremely dubious except in benchmarking code {1} forces garbage collection; extremely dubious except in benchmarking code

Code explicitly invokes garbage collection. Except for specific use in benchmarking, this is very dubious.

In the past, situations where people have explicitly invoked the garbage collector in routines such as close or finalize methods has led to huge performance black holes. Garbage collection can be expensive. Any situation that forces hundreds or thousands of garbage collections will bring the machine to a crawl.

]]>

Method invokes inefficient Boolean constructor; use Boolean.valueOf(...) instead {1} invokes inefficient Boolean constructor; use Boolean.valueOf(...) instead

Creating new instances of java.lang.Boolean wastes memory, since Boolean objects are immutable and there are only two useful values of this type. Use the Boolean.valueOf() method (or Java 1.5 autoboxing) to create Boolean objects instead.

]]>

Method invokes inefficient Number constructor; use static valueOf instead Method {1} invokes inefficient {2} constructor; use {3} instead

Using new Integer(int) is guaranteed to always result in a new object whereas Integer.valueOf(int) allows caching of values to be done by the compiler, class library, or JVM. Using of cached values avoids object allocation and the code will be faster.

Values between -128 and 127 are guaranteed to have corresponding cached instances and using valueOf is approximately 3.5 times faster than using constructor. For values outside the constant range the performance of both styles is the same.

Unless the class must be compatible with JVMs predating Java 1.5, use either autoboxing or the valueOf() method when creating instances of Long, Integer, Short, Character, and Byte.

]]>

Method invokes inefficient floating-point Number constructor; use static valueOf instead Method {1} invokes inefficient {3} constructor; use {4} instead

Using new Double(double) is guaranteed to always result in a new object whereas Double.valueOf(double) allows caching of values to be done by the compiler, class library, or JVM. Using of cached values avoids object allocation and the code will be faster.

Unless the class must be compatible with JVMs predating Java 1.5, use either autoboxing or the valueOf() method when creating instances of Double and Float.

]]>

Method invokes inefficient String.equals(""); use String.length() == 0 instead Method {1} invokes inefficient String.equals(""); use String.length() == 0 instead

An object is compared to the empty String object using the equals() method here. Checking that the String object's length is zero may be faster, and removes String constants from the class file.

]]>

Consider using Locale parameterized version of invoked method Use of non-localized String.toUpperCase() or String.toLowerCase

A String is being converted to upper or lowercase, using the platform's default encoding. This may result in improper conversions when used with international characters. Use the

String.toUpperCase( Locale l )

String.toLowerCase( Locale l )

versions instead.

]]>

Primitive value is unboxed and coerced for ternary operator Primitive value is unboxed and coerced for ternary operator in {1}

A wrapped primitive value is unboxed and converted to another primitive type as part of the evaluation of a conditional ternary operator (the b ? e1 : e2 operator). The semantics of Java mandate that if e1 and e2 are wrapped numeric values, the values are unboxed and converted/coerced to their common type (e.g, if e1 is of type Integer and e2 is of type Float, then e1 is unboxed, converted to a floating point value, and boxed. See JLS Section 15.25.

]]>

Primitive value is boxed and then immediately unboxed Primitive value is boxed and then immediately unboxed in {1}

A primitive is boxed, and then immediately unboxed. This probably is due to a manual boxing in a place where an unboxed value is required, thus forcing the compiler to immediately undo the work of the boxing.

]]>

Primitive value is boxed then unboxed to perform primitive coercion Primitive value is boxed then unboxed to perform primitive coercion in {1}

A primitive boxed value constructed and then immediately converted into a different primitive type (e.g., new Double(d).intValue()). Just perform direct primitive coercion (e.g., (int) d).

]]>

Method allocates a boxed primitive just to call toString Primitive boxed just to call toString in {1}

A boxed primitive is allocated just to call toString(). It is more effective to just use the static form of toString which takes the primitive value. So,

Replace...	With this...
new Integer(1).toString()	Integer.toString(1)
new Long(1).toString()	Long.toString(1)
new Float(1.0).toString()	Float.toString(1.0)
new Double(1.0).toString()	Double.toString(1.0)
new Byte(1).toString()	Byte.toString(1)
new Short(1).toString()	Short.toString(1)
new Boolean(true).toString()	Boolean.toString(true)

]]>

Method allocates an object, only to get the class object Method {1} allocates an object, only to get the class object

This method allocates an object just to call getClass() on it, in order to retrieve the Class object for it. It is simpler to just access the .class property of the class.

]]>

Monitor wait() called on Condition Monitor wait() called on a Condition in {1}

This method calls wait() on a java.util.concurrent.locks.Condition object. Waiting for a Condition should be done using one of the await() methods defined by the Condition interface.

]]>

Random value from 0 to 1 is coerced to the integer 0 Method {1} uses generates a random value from 0 to 1 and then coerces that value to the integer 0

A random value from 0 to 1 is being coerced to the integer value 0. You probably want to multiple the random value by something else before coercing it to an integer, or use the Random.nextInt(n) method.

]]>

Use the nextInt method of Random rather than nextDouble to generate a random integer Method {1} uses the nextDouble method of Random to generate a random integer; using nextInt is more efficient

If r is a java.util.Random, you can generate a random number from 0 to n-1 using r.nextInt(n), rather than using (int)(r.nextDouble() * n).

]]>

Nonconstant string passed to execute method on an SQL statement Method {1} passes a nonconstant String to an execute method on an SQL statement

The method invokes the execute method on an SQL statement with a String that seems to be dynamically generated. Consider using a prepared statement instead. It is more efficient and less vulnerable to SQL injection attacks.

]]>

A prepared statement is generated from a nonconstant String A prepared statement is generated from a nonconstant String at {1}

The code creates an SQL prepared statement from a nonconstant String. If unchecked, tainted data from a user is used in building this String, SQL injection could be used to make the prepared statement do something unexpected and undesirable.

]]>

A thread was created using the default empty run method Method {1} creates a thread using the default empty run method

This method creates a thread without specifying a run method either by deriving from the Thread class, or by passing a Runnable object. This thread, then, does nothing but waste time.

]]>

Possible double check of field Possible doublecheck on {2} in {1}

This method may contain an instance of double-checked locking. This idiom is not correct according to the semantics of the Java memory model. For more information, see the web page http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html.

]]>

Finalizer nulls fields {3} is set to null inside finalize method

This finalizer nulls out fields. This is usually an error, as it does not aid garbage collection, and the object is going to be garbage collected anyway. ]]>

Finalizer only nulls fields {1} only nulls fields

This finalizer does nothing except null out fields. This is completely pointless, and requires that the object be garbage collected, finalized, and then garbage collected again. You should just remove the finalize method. ]]>

Finalizer should be protected, not public {1} is public; should be protected

A class's finalize() method should have protected access, not public.

]]>

Empty finalizer should be deleted {1} is empty and should be deleted

Empty finalize() methods are useless, so they should be deleted.

]]>

Finalizer nullifies superclass finalizer {1} is nullifying {2}.finalize(); is this intended?

This empty finalize() method explicitly negates the effect of any finalizer defined by its superclass. Any finalizer actions defined for the superclass will not be performed. Unless this is intended, delete this method.

]]>

Finalizer does nothing but call superclass finalizer {1} does nothing except call super.finalize(); delete it

The only thing this finalize() method does is call the superclass's finalize() method, making it redundant. Delete it.

]]>

Finalizer does not call superclass finalizer {1} missing call to super.finalize(), so {2}.finalize() doesn't get called

This finalize() method does not make a call to its superclass's finalize() method. So, any finalizer actions defined for the superclass will not be performed. Add a call to super.finalize().

]]>

Explicit invocation of finalizer {1} explicitly invokes {2}

This method contains an explicit invocation of the finalize() method on an object. Because finalizer methods are supposed to be executed once, and only by the VM, this is a bad idea.

If a connected set of objects beings finalizable, then the VM will invoke the finalize method on all the finalizable object, possibly at the same time in different threads. Thus, it is a particularly bad idea, in the finalize method for a class X, invoke finalize on objects referenced by X, because they may already be getting finalized in a separate thread. ]]>

Covariant equals() method defined for enum enum {0} defines equals({0.givenClass})

This class defines an enumeration, and equality on enumerations are defined using object identity. Definine a covariant equals method for an enumeration value is exceptionally bad practice, since it would likely result in having two different enumeration values that compare as equals using the covariant enum method, and as not equal when compared normally. Don't do it.

]]>

Covariant equals() method defined, Object.equals(Object) inherited {0} defines equals({0.givenClass}) method and uses Object.equals(Object)

This class defines a covariant version of the equals() method, but inherits the normal equals(Object) method defined in the base java.lang.Object class. The class should probably define a boolean equals(Object) method.

]]>

equals() method defined that doesn't override Object.equals(Object) {0} defines {1.givenClass} method and uses Object.equals(Object)

This class defines an equals() method, that doesn't override the normal equals(Object) method defined in the base java.lang.Object class. The class should probably define a boolean equals(Object) method.

]]>

equals() method defined that doesn't override equals(Object) {0} defines {1.givenClass} method that doesn't override equals(Object)

This class defines an equals() method, that doesn't override the normal equals(Object) method defined in the base java.lang.Object class. Instead, it inherits an equals(Object) method from a superclass. The class should probably define a boolean equals(Object) method.

]]>

Class doesn't override equals in superclass {0} doesn't override {1.givenClass}

This class extends a class that defines an equals method and adds fields, but doesn't define an equals method itself. Thus, equality on instances of this class will ignore the identity of the subclass and the added fields. Be sure this is what is intended, and that you don't need to override the equals method. Even if you don't need to override the equals method, consider overriding it anyway to document the fact that the equals method for the subclass just return the result of invoking super.equals(o).

]]>

Covariant equals() method defined {0} defines equals({0.givenClass}) method but not equals(Object)

This class defines a covariant version of equals(). To correctly override the equals() method in java.lang.Object, the parameter of equals() must have type java.lang.Object.

]]>

equals method overrides equals in superclass and may not be symmetric {1.class} overrides equals in {2.class.givenClass} and may not be symmetric

This class defines an equals method that overrides an equals method in a superclass. Both equals methods methods use instanceof in the determination of whether two objects are equal. This is fraught with peril, since it is important that the equals method is symetrical (in other words, a.equals(b) == b.equals(a)). If B is a subtype of A, and A's equals method checks that the argument is an instanceof A, and B's equals method checks that the argument is an instanceof B, it is quite likely that the equivalence relation defined by these methods is not symmetric.

]]>

equals method fails for subtypes {1} fails for subtypes

This class has an equals method that will be broken if it is inherited by subclasses. It compares a class literal with the class of the argument (e.g., in class Foo it might check if Foo.class == o.getClass()). It is better to check if this.getClass() == o.getClass().

]]>

Unusual equals method {1} is unusual

This class doesn't do any of the patterns we recognize for checking that the type of the argument is compatible with the type of the this object. There might not be anything wrong with this code, but it is worth reviewing.

]]>

equals method compares class names rather than class objects {1} compares class names rather than class objects

This method checks to see if two objects are the same class by checking to see if the names of their classes are equal. You can have different classes with the same name if they are loaded by different class loaders. Just check to see if the class objects are the same.

]]>

equals method always returns true {1} always returns true

This class defines an equals method that always returns true. This is imaginative, but not very smart. Plus, it means that the equals method is not symmetric.

]]>

equals method always returns false {1} always returns false

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 fundementally, it means that equals is not reflexive, one of the requirements of the equals method.

The likely intended semantics are object identity: that an object is equal to itself. This is the behavior inherited from class Object. If you need to override an equals inherited from a different superclass, you can use use:

public boolean equals(Object o) { return this == o; }

]]>

Huge string constants is duplicated across multiple class files {1} is initialized to a string constant {2} characters long that is duplicated in {3} other class files

A large String constant is duplicated across multiple class files. This is likely because a final field is initialized to a String constant, and the Java language mandates that all references to a final field from other classes be inlined into that classfile. See JDK bug 6447475 for a description of an occurrence of this bug in the JDK and how resolving it reduced the size of the JDK by 1 megabyte.

]]>

Method does not check for null argument {1} does not check for null argument

A parameter to this method has been identified as a value that should always be checked to see whether or not it is null, but it is being dereferenced without a preceding null check.

]]>

equals() method does not check for null argument {1} does not check for null argument

This implementation of equals(Object) violates the contract defined by java.lang.Object.equals() because it does not check for null being passed as the argument. All equals() methods should return false if passed a null value.

]]>

equals() method does not check for null parameter {1} does not check for null parameter

This implementation of equals(Object) violates the contract defined by java.lang.Object.equals() because it does not check for null being passed as the parameter. All equals() methods should return false if passed a null value.

]]>

Covariant compareTo() method defined {0} defines compareTo({0.givenClass}) method but not compareTo(Object)

This class defines a covariant version of compareTo(). To correctly override the compareTo() method in the Comparable interface, the parameter of compareTo() must have type java.lang.Object.

]]>

Use of class without a hashCode() method in a hashed data structure {2} doesn't define a hashCode() method but is used in a hashed data structure

A class defines an equals(Object) method but not a hashCode() method, and thus doesn't fulfill the requirement that equal Objects have equal hashCodes. An instance of this class is used in a hash data structure, making the need to fix this problem of highest importance. ]]>

Class defines hashCode() and uses Object.equals() {0} defines hashCode and uses Object.equals()

This class defines a hashCode() method but inherits its equals() method from java.lang.Object (which defines equality by comparing object references). Although this will probably satisfy the contract that equal objects must have equal hashcodes, it is probably not what was intended by overriding the hashCode() method. (Overriding hashCode() implies that the object's identity is based on criteria more complicated than simple reference equality.)

If you don't think instances of this class will ever be inserted into a HashMap/HashTable, the recommended hashCode implementation to use is:

public int hashCode() {
  assert false : "hashCode not designed";
  return 42; // any arbitrary constant will do 
  }

]]>

Class defines compareTo(...) and uses Object.equals() {0} defines {1.givenClass} and uses Object.equals()

This class defines a compareTo(...) method but inherits its equals() method from java.lang.Object. Generally, the value of compareTo should return zero if and only if equals returns true. If this is violated, weird and unpredictable failures will occur in classes such as PriorityQueue. In Java 5 the PriorityQueue.remove method uses the compareTo method, while in Java 6 it uses the equals method.

From the JavaDoc for the compareTo method in the Comparable interface:

It is strongly recommended, but not strictly required that (x.compareTo(y)==0) == (x.equals(y)). Generally speaking, any class that implements the Comparable interface and violates this condition should clearly indicate this fact. The recommended language is "Note: this class has a natural ordering that is inconsistent with equals."

]]>

Class defines hashCode() but not equals() {0} defines hashCode but not equals

This class defines a hashCode() method but not an equals() method. Therefore, the class may violate the invariant that equal objects must have equal hashcodes.

]]>

Class defines equals() and uses Object.hashCode() {0} defines equals and uses Object.hashCode()

This class overrides equals(Object), but does not override hashCode(), and inherits the implementation of hashCode() from java.lang.Object (which returns the identity hash code, an arbitrary value assigned to the object by the VM). Therefore, the class is very likely to violate the invariant that equal objects must have equal hashcodes.

If you don't think instances of this class will ever be inserted into a HashMap/HashTable, the recommended hashCode implementation to use is:

public int hashCode() {
  assert false : "hashCode not designed";
  return 42; // any arbitrary constant will do 
  }

]]>

Class inherits equals() and uses Object.hashCode() {0} inherits equals and uses Object.hashCode()

This class inherits equals(Object) from an abstract superclass, and hashCode() from java.lang.Object (which returns the identity hash code, an arbitrary value assigned to the object by the VM). Therefore, the class is very likely to violate the invariant that equal objects must have equal hashcodes.

If you don't want to define a hashCode method, and/or don't believe the object will ever be put into a HashMap/Hashtable, define the hashCode() method to throw UnsupportedOperationException.

]]>

Class defines equals() but not hashCode() {0} defines equals but not hashCode

This class overrides equals(Object), but does not override hashCode(). Therefore, the class may violate the invariant that equal objects must have equal hashcodes.

]]>

Abstract class defines covariant equals() method Abstract {0} defines equals({0.givenClass}) method

This class defines a covariant version of equals(). To correctly override the equals() method in java.lang.Object, the parameter of equals() must have type java.lang.Object.

]]>

Comparison of String objects using == or != Comparison of String objects using == or != in {1}

This code compares java.lang.String objects for reference equality using the == or != operators. Unless both strings are either constants in a source file, or have been interned using the String.intern() method, the same string value may be represented by two different String objects. Consider using the equals(Object) method instead.

]]>

Comparison of String parameter using == or != Comparison of String parameter using == or != in {1}

This code compares a java.lang.String parameter for reference equality using the == or != operators. Requiring callers to pass only String constants or interned strings to a method is unnecessarily fragile, and rarely leads to measurable performance gains. Consider using the equals(Object) method instead.

]]>

Abstract class defines covariant compareTo() method Abstract {0} defines compareTo({0.givenClass}) method

]]>

Field not guarded against concurrent access {1.givenClass} not guarded against concurrent access; locked {2}% of time

This field is annotated with net.jcip.annotations.GuardedBy, but can be accessed in a way that seems to violate the annotation.

]]>

Mutable servlet field {1} is a mutable servlet field

A web server generally only creates one instance of servlet or jsp class (i.e., treates the class as a Singleton), and will have multiple threads invoke methods on that instance to service multiple simultaneous requests. Thus, having a mutable instance field generally creates race conditions. ]]>

Inconsistent synchronization Inconsistent synchronization of {1}; locked {2}% of time

The fields of this class appear to be accessed inconsistently with respect to synchronization. This bug report indicates that the bug pattern detector judged that

The class contains a mix of locked and unlocked accesses,
At least one locked access was performed by one of the class's own methods, and
The number of unsynchronized field accesses (reads and writes) was no more than one third of all accesses, with writes being weighed twice as high as reads

A typical bug matching this bug pattern is forgetting to synchronize one of the methods in a class that is intended to be thread-safe.

You can select the nodes labeled "Unsynchronized access" to show the code locations where the detector believed that a field was accessed without synchronization.

Note that there are various sources of inaccuracy in this detector; for example, the detector cannot statically detect all situations in which a lock is held. Also, even when the detector is accurate in distinguishing locked vs. unlocked accesses, the code in question may still be correct.

]]>

Naked notify Naked notify in {1}

A call to notify() or notifyAll() was made without any (apparent) accompanying modification to mutable object state. In general, calling a notify method on a monitor is done because some condition another thread is waiting for has become true. However, for the condition to be meaningful, it must involve a heap object that is visible to both threads.

This bug does not necessarily indicate an error, since the change to mutable object state may have taken place in a method which then called the method containing the notification.

]]>

Public static method may expose internal representation by returning array public static {1} may expose internal representation by returning {2.givenClass}

A public static method returns a reference to an array that is part of the static state of the class. Any code that calls this method can freely modify the underlying array. One fix is to return a copy of the array.

]]>

May expose internal representation by returning reference to mutable object {1} may expose internal representation by returning {2.givenClass}

Returning a reference to a mutable object value stored in one of the object's fields exposes the internal representation of the object. If instances are accessed by untrusted code, and unchecked changes to the mutable object would compromise security or other important properties, you will need to do something different. Returning a new copy of the object is better approach in many situations.

]]>

May expose internal representation by incorporating reference to mutable object {1} may expose internal representation by storing an externally mutable object into {2.givenClass}

This code stores a reference to an externally mutable object into the internal representation of the object. If instances are accessed by untrusted code, and unchecked changes to the mutable object would compromise security or other important properties, you will need to do something different. Storing a copy of the object is better approach in many situations.

]]>

May expose internal static state by storing a mutable object into a static field {1} may expose internal static state by storing a mutable object into a static field {2}

This code stores a reference to an externally mutable object into a static field. If unchecked changes to the mutable object would compromise security or other important properties, you will need to do something different. Storing a copy of the object is better approach in many situations.

]]>

Invokes run on a thread (did you mean to start it instead?) {1} explicitly invokes run on a thread (did you mean to start it instead?)

This method explicitly invokes run() on an object. In general, classes implement the Runnable interface because they are going to have their run() method invoked in a new thread, in which case Thread.start() is the right method to call.

]]>

Method spins on field Spinning on {2.givenClass} in {1}

This method spins in a loop which reads a field. The compiler may legally hoist the read out of the loop, turning the code into an infinite loop. The class should be changed so it uses proper synchronization (including wait and notify calls).

]]>

Potentially dangerous use of non-short-circuit logic Potentially dangerous use of non-short-circuit logic in {1}

This code seems to be using non-short-circuit logic (e.g., & or |) rather than short-circuit logic (&& or ||). In addition, it seem possible that, depending on the value of the left hand side, you might not want to evaluate the right hand side (because it would have side effects, could cause an exception or could be expensive.

Non-short-circuit logic causes both sides of the expression to be evaluated even when the result can be inferred from knowing the left-hand side. This can be less efficient and can result in errors if the left-hand side guards cases when evaluating the right-hand side can generate an error.

See the Java Language Specification for details

]]>

Questionable use of non-short-circuit logic Questionable use of non-short-circuit logic in {1}

This code seems to be using non-short-circuit logic (e.g., & or |) rather than short-circuit logic (&& or ||). Non-short-circuit logic causes both sides of the expression to be evaluated even when the result can be inferred from knowing the left-hand side. This can be less efficient and can result in errors if the left-hand side guards cases when evaluating the right-hand side can generate an error.

See the Java Language Specification for details

]]>

Wait with two locks held wait() with two locks held in {1}

Waiting on a monitor while two locks are held may cause deadlock. Performing a wait only releases the lock on the object being waited on, not any other locks. This not necessarily a bug, but is worth examining closely.

]]>

Notify with two locks held notify() or notifyAll*() with two locks held in {1}

The code calls notify() or notifyAll() while two locks are held. If this notification is intended to wake up a wait() that is holding the same locks, it may deadlock, since the wait will only give up one lock and the notify will be unable to get both locks, and thus the notify will not succeed. If there is also a warning about a two lock wait, the probably of a bug is quite high.

]]>

Unconditional wait Unconditional wait in {1}

This method contains a call to java.lang.Object.wait() which is not guarded by conditional control flow. The code should verify that condition it intends to wait for is not already satisfied before calling wait; any previous notifications will be ignored.

]]>

Uninitialized read of field in constructor Uninitialized read of {2.name} in {1}

This constructor reads a field which has not yet been assigned a value. This is often caused when the programmer mistakenly uses the field instead of one of the constructor's parameters.

]]>

Unsynchronized get method, synchronized set method {1} is unsynchronized, {2} is synchronized

This class contains similarly-named get and set methods where the set method is synchronized and the get method is not. This may result in incorrect behavior at runtime, as callers of the get method will not necessarily see a consistent state for the object. The get method should be made synchronized.

]]>

Initialization circularity Initialization circularity between {0} and {1}

A circularity was detected in the static initializers of the two classes referenced by the bug instance. Many kinds of unexpected behavior may arise from such circularity.

]]>

Superclass uses subclass during initialization Initialization of {0} accesses class {2}, which isn't initialized yet

During the initialization of a class, the class makes an active use of a subclass. That subclass will not yet be initialized at the time of this use. For example, in the following code, foo will be null.

public class CircularClassInitialization {
	static class InnerClassSingleton extends CircularClassInitialization {
		static InnerClassSingleton singleton = new InnerClassSingleton();
	}
	
	static CircularClassInitialization foo = InnerClassSingleton.singleton;
}

]]>

Iterator next() method can't throw NoSuchElement exception {1} can't throw NoSuchElement exception

This class implements the java.util.Iterator interface. However, its next() method is not capable of throwing java.util.NoSuchElementException. The next() method should be changed so it throws NoSuchElementException if is called when there are no more elements to return.

]]>

Synchronization on interned String could lead to deadlock Synchronization on interned String could deadlock in {1}

The code synchronizes on interned String.

private static String LOCK = "LOCK";
...
  synchronized(LOCK) { ...}
...

Constant Strings are interned and shared across all other classes loaded by the JVM. Thus, this could is locking on something that other code might also be locking. This could result in very strange and hard to diagnose blocking and deadlock behavior. See http://www.javalobby.org/java/forums/t96352.html and http://jira.codehaus.org/browse/JETTY-352.

]]>

Synchronization on Boolean could lead to deadlock Synchronization on Boolean could deadlock in {1}

The code synchronizes on a boxed primitive constant, such as an Boolean.

private static Boolean inited = Boolean.FALSE;
...
  synchronized(inited) { 
    if (!inited) {
       init();
       inited = Boolean.TRUE;
       }
     }
...

Since there normally exist only two Boolean objects, this code could be synchronizing on the same object as other, unrelated code, leading to unresponsiveness and possible deadlock

]]>

Synchronization on boxed primative values Synchronization on {2} in {1}

The code synchronizes on an apparently unshared boxed primitive, such as an Integer.

private static final Integer fileLock = new Integer(1);
...
  synchronized(fileLock) { 
     .. do something ..
     }
...

It would be much better, in this code, to redeclare fileLock as

private static final Object fileLock = new Object();

The existing code might be OK, but it is confusing and a future refactoing, such as the "Remove Boxing" refactoring in IntelliJ, might replace this with the use of an intern'd Integer object shared throughout the JVM, leading to very confusing behavior and potential deadlock.

]]>

Synchronization on boxed primative could lead to deadlock Synchronization on {2} could deadlock in {1}

The code synchronizes on a boxed primitive constant, such as an Integer.

private static Integer count = 0;
...
  synchronized(count) { 
     count++;
     }
...

Since Integer objects can be cached and shared, this code could be synchronizing on the same object as other, unrelated code, leading to unresponsiveness and possible deadlock

]]>

Empty synchronized block Empty synchronized block in {1}

The code contains an empty synchronized block:

synchronized() {}

Empty synchronized blocks are far more subtle and hard to use correctly than most people recognize, and empty synchronized blocks are almost never a better solution than less contrived solutions.

]]>

Inconsistent synchronization Inconsistent synchronization of {1}; locked {2}% of the time

The fields of this class appear to be accessed inconsistently with respect to synchronization. This bug report indicates that the bug pattern detector judged that

The class contains a mix of locked and unlocked accesses,
At least one locked access was performed by one of the class's own methods, and
The number of unsynchronized field accesses (reads and writes) was no more than one third of all accesses, with writes being weighed twice as high as reads

A typical bug matching this bug pattern is forgetting to synchronize one of the methods in a class that is intended to be thread-safe.

]]>

Synchronization on field in futile attempt to guard that field Synchronization on {2.givenClass} in futile attempt to guard it

This method synchronizes on a field in what appears to be an attempt to guard against simultaneous updates to that field. But guarding a field gets a lock on the referenced object, not on the field. This may not provide the mutual exclusion you need, and other threads might be obtaining locks on the referenced objects (for other purposes). An example of this pattern would be:

private Long myNtfSeqNbrCounter = new Long(0);
private Long getNotificationSequenceNumber() {
     Long result = null;
     synchronized(myNtfSeqNbrCounter) {
         result = new Long(myNtfSeqNbrCounter.longValue() + 1);
         myNtfSeqNbrCounter = new Long(result.longValue());
     }
     return result;
 }

]]>

Method synchronizes on an updated field {1} synchronizes on updated field {2.givenClass}

This method synchronizes on an object referenced from a mutable field. This is unlikely to have useful semantics, since different threads may be synchronizing on different objects.

]]>

Field should be moved out of an interface and made package protected {1} should be moved out of an interface and made package protected

A final static field that is defined in an interface references a mutable object such as an array or hashtable. This mutable object could be changed by malicious code or by accident from another package. To solve this, the field needs to be moved to a class and made package protected to avoid this vulnerability.

]]>

Field should be both final and package protected {1} should be both final and package protected

A mutable static field could be changed by malicious code or by accident from another package. The field could be made package protected and/or made final to avoid this vulnerability.

]]>

Field isn't final but should be {1} isn't final but should be

A mutable static field could be changed by malicious code or by accident from another package. The field could be made final to avoid this vulnerability.

]]>

Field should be package protected {1} should be package protected

A mutable static field could be changed by malicious code or by accident. The field could be made package protected to avoid this vulnerability.

]]>

Field is a mutable Hashtable {1} is a mutable Hashtable

A final static field references a Hashtable and can be accessed by malicious code or by accident from another package. This code can freely modify the contents of the Hashtable.

]]>

Field is a mutable array {1} is a mutable array

A final static field references an array and can be accessed by malicious code or by accident from another package. This code can freely modify the contents of the array.

]]>

Field isn't final and can't be protected from malicious code {1} isn't final and can't be protected from malicious code

A mutable static field could be changed by malicious code or by accident from another package. Unfortunately, the way the field is used doesn't allow any easy fix to this problem.

]]>

Ambiguous invocation of either an inherited or outer method Ambiguous invocation of either an outer or inherited method {2} in {1}

An inner class is invoking a method that could be resolved to either a inherited method or a method defined in an outer class. By the Java semantics, it will be resolved to invoke the inherited method, but this may not be want you intend. If you really intend to invoke the inherited method, invoke it by invoking the method on super (e.g., invoke super.foo(17)), and thus it will be clear to other readers of your code and to FindBugs that you want to invoke the inherited method, not the method in the outer class.

]]>

Class names shouldn't shadow simple name of superclass The class name {0} shadows the simple name of the superclass {1}

This class has a simple name that is identical to that of its superclass, except that its superclass is in a different package (e.g., alpha.Foo extends beta.Foo). This can be exceptionally confusing, create lots of situations in which you have to look at import statements to resolve references and creates many opportunities to accidently define methods that do not override methods in their superclasses.

]]>

Class names shouldn't shadow simple name of implemented interface The class name {0} shadows the simple name of implemented interface {1}

This class/interface has a simple name that is identical to that of an implemented/extended interface, except that the interface is in a different package (e.g., alpha.Foo extends beta.Foo). This can be exceptionally confusing, create lots of situations in which you have to look at import statements to resolve references and creates many opportunities to accidently define methods that do not override methods in their superclasses.

]]>

Class names should start with an upper case letter The class name {0} doesn't start with an upper case letter

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).

]]>

Method names should start with a lower case letter The method name {1} doesn't start with a lower case letter

Methods should be verbs, in mixed case with the first letter lowercase, with the first letter of each internal word capitalized.

]]>

Field names should start with a lower case letter The field name {1} doesn't start with a lower case letter

Names of fields that are not final should be in mixed case with a lowercase first letter and the first letters of subsequent words capitalized.

]]>

Very confusing method names VERY confusing to have methods {1} and {3}

The referenced methods have names that differ only by capitalization. This is very confusing because if the capitalization were identical then one of the methods would override the other.

]]>

Very confusing method names VERY confusing (but perhaps intentional) to have methods {1} and {3}

The referenced methods have names that differ only by capitalization. This is very confusing because if the capitalization were identical then one of the methods would override the other. From the existence of other methods, it seems that the existence of both of these methods is intentional, but is sure is confusing. You should try hard to eliminate one of them, unless you are forced to have both due to frozen APIs.

]]>

Method doesn't override method in superclass due to wrong package for parameter {1} doesn't override method in superclass because parameter type {4} doesn't match superclass parameter type {5}

The method in the subclass doesn't override a similar method in a superclass because the type of a parameter doesn't exactly match the type of the corresponding parameter in the superclass. For example, if you have:

import alpha.Foo;
public class A {
  public int f(Foo x) { return 17; }
}
----
import beta.Foo;
public class B extends A {
  public int f(Foo x) { return 42; }
}

The f(Foo) method defined in class B doesn't override the f(Foo) method defined in class A, because the argument types are Foo's from different packages.

]]>

Method doesn't override method in superclass due to wrong package for parameter {1} doesn't override method in superclass because parameter type {4} doesn't match superclass parameter type {5}

import alpha.Foo;
public class A {
  public int f(Foo x) { return 17; }
}
----
import beta.Foo;
public class B extends A {
  public int f(Foo x) { return 42; }
  public int f(alpha.Foo x) { return 27; }
}

The f(Foo) method defined in class B doesn't override the f(Foo) method defined in class A, because the argument types are Foo's from different packages.

In this case, the subclass does define a method with a signature identical to the method in the superclass, so this is presumably understood. However, such methods are exceptionally confusing. You should strongly consider removing or deprecating the method with the similar but not identical signature.

]]>

Confusing method names Confusing to have methods {1} and {3}

The referenced methods have names that differ only by capitalization.

]]>

Apparent method/constructor confusion Method {1} was probably intended to be a constructor

This regular method has the same name as the class it is defined in. It is likely that this was intended to be a constructor. If it was intended to be a constructor, remove the declaration of a void return value. If you had accidently defined this method, realized the mistake, defined a proper constructor but can't get rid of this method due to backwards compatibility, deprecate the method.

]]>

Class defines hashcode(); should it be hashCode()? Class {0} defines hashcode(); should it be hashCode()?

This class defines a method called hashcode(). This method does not override the hashCode() method in java.lang.Object, which is probably what was intended.

]]>

Class defines tostring(); should it be toString()? Class {0} defines tostring(); should it be toString()?

This class defines a method called tostring(). This method does not override the toString() method in java.lang.Object, which is probably what was intended.

]]>

Class defines equal(); should it be equals()? Class {0} defines equal(); should it be equals()?

This class defines a method equal(Object). This method does not override the equals(Object) method in java.lang.Object, which is probably what was intended.

]]>

Class is not derived from an Exception, even though it is named as such Class {0} is not derived from an Exception, even though it is named as such

This class is not derived from another exception, but ends with 'Exception'. This will be confusing to users of this class.

]]>

Method ignores results of InputStream.read() {1} ignores result of {2}

This method ignores the return value of one of the variants of java.io.InputStream.read() which can return multiple bytes. If the return value is not checked, the caller will not be able to correctly handle the case where fewer bytes were read than the caller requested. This is a particularly insidious kind of bug, because in many programs, reads from input streams usually do read the full amount of data requested, causing the program to fail only sporadically.

]]>

Method ignores results of InputStream.skip() {1} ignores result of {2}

This method ignores the return value of java.io.InputStream.skip() which can skip multiple bytes. If the return value is not checked, the caller will not be able to correctly handle the case where fewer bytes were skipped than the caller requested. This is a particularly insidious kind of bug, because in many programs, skips from input streams usually do skip the full amount of data requested, causing the program to fail only sporadically. With Buffered streams, however, skip() will only skip data in the buffer, and will routinely fail to skip the requested number of bytes.

]]>

The readResolve method must not be declared as a static method. {1} should be declared as an instance method rather than a static method

In order for the readResolve method to be recognized by the serialization mechanism, it must not be declared as a static method.

]]>

private readResolve method not inherited by subclasses private readResolve method in {0} not inherited by subclasses.

This class defines a private readResolve method. Since it is private, it won't be inherited by subclasses. This might be intentional and OK, but should be reviewed to ensure it is what is intended.

]]>

The readResolve method must be declared with a return type of Object. The method {1} must be declared with a return type of Object rather than {1.returnType}

In order for the readResolve method to be recognized by the serialization mechanism, it must be declared to have a return type of Object.

]]>

Transient field of class that isn't Serializable. {1.givenClass} is transient but {0} isn't Serializable

The field is marked as transient, but the class isn't Serializable, so marking it as transient has absolutely no effect. This may be leftover marking from a previous version of the code in which the class was transient, or it may indicate a misunderstanding of how serialization works.

]]>

Transient field that isn't set by deserialization. The field {1} is transient but isn't set by deserialization

This class contains a field that is updated at multiple places in the class, thus it seems to be part of the state of the class. However, since the field is marked as transient and not set in readObject or readResolve, it will contain the default value in any deserialized instance of the class.

]]>

Method must be private in order for serialization to work The method {1.givenClass} must be private to be invoked in serialization/deserialization of {0}

This class implements the Serializable interface, and defines a method for custom serialization/deserialization. But since that method isn't declared private, it will be silently ignored by the serialization/deserialization API.

]]>

Class is Externalizable but doesn't define a void constructor {0} is Externalizable but doesn't define a void constructor

This class implements the Externalizable interface, but does not define a void constructor. When Externalizable objects are deserialized, they first need to be constructed by invoking the void constructor. Since this class does not have one, serialization and deserialization will fail at runtime.

]]>

Class is Serializable but its superclass doesn't define a void constructor {0} is Serializable but its superclass doesn't define an accessible void constructor

This class implements the Serializable interface and its superclass does not. When such an object is deserialized, the fields of the superclass need to be initialized by invoking the void constructor of the superclass. Since the superclass does not have one, serialization and deserialization will fail at runtime.

]]>

Class is Serializable, but doesn't define serialVersionUID {0} is Serializable; consider declaring a serialVersionUID

This class implements the Serializable interface, but does not define a serialVersionUID field. A change as simple as adding a reference to a .class object will add synthetic fields to the class, which will unfortunately change the implicit serialVersionUID (e.g., adding a reference to String.class will generate a static field class$java$lang$String). Also, different source code to bytecode compilers may use different naming conventions for synthetic variables generated for references to class objects or inner classes. To ensure interoperability of Serializable across versions, consider adding an explicit serialVersionUID.

]]>

Comparator doesn't implement Serializable {0} implements Comparator but not Serializable

This class implements the Comparator interface. You should consider whether or not it should also implement the Serializable interface. If a comparator is used to construct an ordered collection such as a TreeMap, then the TreeMap will be serializable only if the comparator is also serializable. As most comparators have little or no state, making them serializable is generally easy and good defensive programming.

]]>

Switch statement found where one case falls through to the next case Switch statement found in {1} where one case falls through to the next case

This method contains a switch statement where one case branch will fall through to the next case. Usually you need to end this case with a break or return.

]]>

Dead store due to switch statement fall through Value of {2.givenClass} from previous case is overwritten here due to switch statement fall through

A value stored in the previous switch case is overwritten here due to a switch fall through. It is likely that you forgot to put a break or return at the end of the previous case.

]]>

Class's writeObject() method is synchronized but nothing else is {0}'s writeObject method is synchronized but nothing else is

This class has a writeObject() method which is synchronized; however, no other method of the class is synchronized.

]]>

Class's readObject() method is synchronized {0}'s readObject method is synchronized

This serializable class defines a readObject() which is synchronized. By definition, an object created by deserialization is only reachable by one thread, and thus there is no need for readObject() to be synchronized. If the readObject() method itself is causing the object to become visible to another thread, that is an example of very dubious coding style.

]]>

serialVersionUID isn't static {1} isn't static

This class defines a serialVersionUID field that is not static. The field should be made static if it is intended to specify the version UID for purposes of serialization.

]]>

serialVersionUID isn't final {1} isn't final

This class defines a serialVersionUID field that is not final. The field should be made final if it is intended to specify the version UID for purposes of serialization.

]]>

serialVersionUID isn't long {1} isn't long

This class defines a serialVersionUID field that is not long. The field should be made long if it is intended to specify the version UID for purposes of serialization.

]]>

Non-transient non-serializable instance field in serializable class Class {0} defines non-transient non-serializable instance field {1.name}

This Serializable class defines a non-primitive instance field which is neither transient, Serializable, or java.lang.Object, and does not appear to implement the Externalizable interface or the readObject() and writeObject() methods. Objects of this class will not be deserialized correctly if a non-Serializable object is stored in this field.

]]>

Non-serializable class has a serializable inner class {0} is serializable but also an inner class of a non-serializable class

This Serializable class is an inner class of a non-serializable class. Thus, attempts to serialize it will also attempt to associate instance of the outer class with which it is associated, leading to a runtime error.

If possible, making the inner class a static inner class should solve the problem. Making the outer class serializable might also work, but that would mean serializing an instance of the inner class would always also serialize the instance of the outer class, which it often not what you really want. ]]>

Serializable inner class {0} is serializable and an inner class

This Serializable class is an inner class. Any attempt to serialize it will also serialize the associated outer instance. The outer instance is serializable, so this won't fail, but it might serialize a lot more data than intended. If possible, making the inner class a static inner class (also known as a nested class) should solve the problem. ]]>

Non-serializable value stored into instance field of a serializable class {2} stored into non-transient field {1.givenClass}

A non-serializable value is stored into a non-transient field of a serializable class.

]]>

Constructor invokes Thread.start() {1} invokes {2}

The constructor starts a thread. This is likely to be wrong if the class is ever extended/subclassed, since the thread will be started before the subclass constructor is started.

]]>

Unread field: should this field be static? Unread field: {1}; should this field be static?

This class contains an instance final field that is initialized to a compile-time static value. Consider making the field static.

]]>

Unused field Unused field: {1}

This field is never used. Consider removing it from the class.

]]>

Unread field Unread field: {1}

This field is never read. Consider removing it from the class.

]]>

Complicated, subtle or wrong increment in for-loop Complicated, subtle or wrong increment in for-loop {1}

Are you sure this for loop is incrementing the correct variable? It appears that another variable is being initialized and checked by the for loop.

]]>

Field only ever set to null Field only ever set to null: {1}

All writes to this field are of the constant value null, and thus all reads of the field will return null. Check for errors, or remove it if it is useless.

]]>

Unwritten field Unwritten field: {1}

This field is never written. All reads of it will return the default value. Check for errors (should it have been initialized?), or remove it if it is useless.

]]>

Write to static field from instance method Write to static field {2} from instance method {1}

This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.

]]>

Load of known null value Load of known null value in {1}

The variable referenced at this point is known to be null due to an earlier check against null. Although this is valid, it might be a mistake (perhaps you intended to refer to a different variable, or perhaps the earlier check to see if the variable is null should have been a check to see if it was nonnull).

]]>

Immediate dereference of the result of readLine() Immediate dereference of the result of readLine() in {1}

The result of invoking readLine() is immediately dereferenced. If there are no more lines of text to read, readLine() will return null and dereferencing that will generate a null pointer exception.

]]>

Read of unwritten field Read of unwritten field {2.name} in {1}

The program is dereferencing a field that does not seem to ever have a non-null value written to it. Dereferencing this value will generate a null pointer exception.

]]>

Should be a static inner class Should {0} be a _static_ inner class?

]]>

Read of field not initialized in constructor Read of field not initialized in constructor at {1}

This is a read of a field is never initialized within any constructor, and is therefore could be null after the object is initialized. This might be a coding error, or else the class containing the field is written in a way that depends upon methods being called in some specific order (a little bit dodgy, but not necessarily wrong).

]]>

Field not initialized in constructor {1.givenClass} not initialized in constructor

This field is never initialized within any constructor, and is therefore could be null after the object is constructed. This could be a either an error or a questionable design, since it means a null pointer exception will be generated if that field is dereferenced before being initialized.

]]>

Could be refactored into a named static inner class The class {0} could be refactored into a named _static_ inner class

This class is an inner class, but does not use its embedded reference to the object which created it. This reference makes the instances of the class larger, and may keep the reference to the creator object alive longer than necessary. If possible, the class should be made into a static inner class. Since anonymous inner classes cannot be marked as static, doing this will require refactoring the inner class so that it is a named inner class.

]]>

Could be refactored into a static inner class The class {0} could be refactored into a _static_ inner class

This class is an inner class, but does not use its embedded reference to the object which created it except during construction of the inner object. This reference makes the instances of the class larger, and may keep the reference to the creator object alive longer than necessary. If possible, the class should be made into a static inner class. Since the reference to the outer object is required during construction of the inner instance, the inner class will need to be refactored so as to pass a reference to the outer instance to the constructor for the inner class.

]]>

Wait not in loop Wait not in loop in {1}

This method contains a call to java.lang.Object.wait() which is not in a loop. If the monitor is used for multiple conditions, the condition the caller intended to wait for might not be the one that actually occurred.

]]>

Condition.await() not in loop Condition.await() not in loop in {1}

This method contains a call to java.util.concurrent.await() (or variants) which is not in a loop. If the object is used for multiple conditions, the condition the caller intended to wait for might not be the one that actually occurred.

]]>

Using notify() rather than notifyAll() Using notify rather than notifyAll in {1}

This method calls notify() rather than notifyAll(). Java monitors are often used for multiple conditions. Calling notify() only wakes up one thread, meaning that the thread woken up might not be the one waiting for the condition that the caller just satisfied.

]]>

Method checks to see if result of String.indexOf is positive {1} checks to see if result of String.indexOf is positive

The method invokes String.indexOf and checks to see if the result is positive or non-positive. It is much more typical to check to see if the result is negative or non-negative. It is positive only if the substring checked for occurs at some place other than at the beginning of the String.

]]>

Method discards result of readLine after checking if it is nonnull {1} discards result of readLine after checking if it is nonnull

The value returned by readLine is discarded after checking to see if the return value is non-null. In almost all situations, if the result is non-null, you will want to use that non-null value. Calling readLine again will give you a different line.

]]>

Method ignores return value {1} ignores return value of {2}

The return value of this method should be checked. One common cause of this warning is to invoke a method on an immutable object, thinking that it updates the object. For example, in the following code fragment,

String dateString = getHeaderField(name);
dateString.trim();

the programmer seems to be thinking that the trim() method will update the String referenced by dateString. But since Strings are immutable, the trim() function returns a new String value, which is being ignored here. The code should be corrected to:

String dateString = getHeaderField(name);
dateString = dateString.trim();

]]>

Method ignores exceptional return value {1} ignores exceptional return value of {2}

This method returns a value that is not checked. The return value should be checked since it can indicate an unusual or unexpected function execution. For example, the File.delete() method returns false if the file could not be successfully deleted (rather than throwing an Exception). If you don't check the result, you won't notice if the method invocation signals unexpected behavior by returning an atypical return value.

]]>

Exception created and dropped rather than thrown {1} forgets to throw {2.givenClass}

This code creates an exception (or error) object, but doesn't do anything with it. For example, something like

if (x < 0)
  new IllegalArgumentException("x must be nonnegative");

It was probably the intent of the programmer to throw the created exception:

if (x < 0)
  throw new IllegalArgumentException("x must be nonnegative");

]]>

Method ignores return value {1} ignores return value of {2}

String dateString = getHeaderField(name);
dateString.trim();

String dateString = getHeaderField(name);
dateString = dateString.trim();

]]>

Null pointer dereference Null pointer dereference of {2.givenClass} in {1}

A null pointer is dereferenced here. This will lead to a NullPointerException when the code is executed.

]]>

Store of null value into field annotated NonNull Store of null value into field {2.givenClass} annotated NonNull at {1}

A value that could be null is stored into a field that has been annotated as NonNull.

]]>

Null pointer dereference in method on exception path Null pointer dereference of {2.givenClass} in {1} on exception path

A pointer which is null on an exception path is dereferenced here. This will lead to a NullPointerException when the code is executed. Note that because FindBugs currently does not prune infeasible exception paths, this may be a false warning.

Also note that FindBugs considers the default case of a switch statement to be an exception path, since the default case is often infeasible.

]]>

Possible null pointer dereference Possible null pointer dereference of {2.givenClass} in {1}

There is a branch of statement that, if executed, guarantees that a null value will be dereferenced, which would generate a NullPointerException when the code is executed. Of course, the problem might be that the branch or statement is infeasible and that the null pointer exception can't ever be executed; deciding that is beyond the ability of FindBugs.

]]>

Possible null pointer dereference on path that might be infeasible Possible null pointer dereference of {2.givenClass} on path that might be infeasible in {1}

]]>

Possible null pointer dereference in method on exception path Possible null pointer dereference of {2.givenClass} in {1} on exception path

A reference value which is null on some exception control path is dereferenced here. This may lead to a NullPointerException when the code is executed. Note that because FindBugs currently does not prune infeasible exception paths, this may be a false warning.

Also note that FindBugs considers the default case of a switch statement to be an exception path, since the default case is often infeasible.

]]>

Possible null pointer dereference due to return value of called method Possible null pointer dereference in {1} due to return value of called method

A reference value which is null on some exception control path is dereferenced here. This may lead to a NullPointerException when the code is executed. The value may be null because it was returned from a method which is known to return possibly-null values.

]]>

Non-virtual method call passes null for unconditionally dereferenced parameter Non-virtual method call in {1} passes null for unconditionally dereferenced parameter of {2.givenClass}

A possibly-null value is passed to a method which unconditionally dereferences it. This will almost certainly result in a null pointer exception.

]]>

Method call passes null for unconditionally dereferenced parameter Method call in {1} passes null for unconditionally dereferenced parameter of {2.givenClass}

A possibly-null value is passed at a call site where all known target methods will unconditionally dereference it. This is very likely to result in a null pointer exception.

]]>

Method call passes null for unconditionally dereferenced parameter Method call in {1} passes null for unconditionally dereferenced parameter of {2.givenClass}

This method call passes a null value to a method which might dereference it unconditionally.

]]>

Method call passes null to a nonnull parameter Method call in {1} passes null to a nonnull parameter of {2.givenClass}

This method passes a null value as the parameter of a method which must be nonnull. Either this parameter has been explicitly marked as @Nonnull, or analysis has determined that this parameter is always dereferenced.

]]>

Method may return null, but is declared @NonNull Method {1} may return null, but is declared @NonNull

This method may return a null value, but the method (or a superclass method which it overrides) is declared to return @NonNull.

]]>

Clone method may return null {1} may return null

This clone method seems to return null in some circumstances, but clone is never allowed to return a null value. If you are convinced this path is unreachable, throw an AssertionError instead.

]]>

toString method may return null {1} may return null

This toString method seems to return null in some circumstances. A liberal reading of the spec could be interpreted as allowing this, but it is probably a bad idea and could cause other code to break. Return the empty string or some other appropriate string rather than null.

]]>

Null value is guaranteed to be dereferenced {2.givenClass} could be null and is guaranteed to be dereferenced in {1}

There is a statement or branch that if executed guarantees that a value is null at this point, and that value that is guaranteed to be dereferenced (except on forward paths involving runtime exceptions).

]]>

Value is null and guaranteed to be dereferenced on exception path {2.name} is null guaranteed to be dereferenced in {1} on exception path

There is a statement or branch on an exception path that if executed guarantees that a value is null at this point, and that value that is guaranteed to be dereferenced (except on forward paths involving runtime exceptions).

]]>

Static initializer creates instance before all static final fields assigned Static initializer for {0} creates instance before all static final fields assigned

The class's static initializer creates an instance of the class before all of the static final fields are assigned.

]]>

Method may fail to close stream {1} may fail to close stream

The method creates an IO stream object, does not assign it to any fields, pass it to other methods that might close it, or return it, and does not appear to close the stream on all paths out of the method. This may result in a file descriptor leak. It is generally a good idea to use a finally block to ensure that streams are closed.

]]>

Method may fail to close stream on exception {1} may fail to close stream on exception

The method creates an IO stream object, does not assign it to any fields, pass it to other methods, or return it, and does not appear to close it on all possible exception paths out of the method. This may result in a file descriptor leak. It is generally a good idea to use a finally block to ensure that streams are closed.

]]>

Consider returning a zero length array rather than null Should {1} return a zero length array rather than null?

It is often a better design to return a length zero array rather than a null reference to indicate that there are no results (i.e., an empty list of results). This way, no explicit check for null is needed by clients of the method.

On the other hand, using null to indicate "there is no answer to this question" is probably appropriate. For example, File.listFiles() returns an empty list if given a directory containing no files, and returns null if the file is not a directory.

]]>

Useless control flow Useless control flow in {1}

This method contains a useless control flow statement, where control flow continues onto the same place regardless of whether or not the branch is taken. For example, this is caused by having an empty statement block fot an if statement:

    if (argv.length == 0) {
	// TODO: handle this case
	}

]]>

Useless control flow to next line Useless control flow to next line in {1}

This method contains a useless control flow statement in which control flow follows to the same or following line regardless of whether or not the branch is taken. Often, this is caused by inadvertently using an empty statement as the body of an if statement, e.g.:

    if (argv.length == 1);
        System.out.println("Hello, " + argv[0]);

]]>

Nullcheck of value previously dereferenced Nullcheck of {2.givenClass} at {4.lineNumber} of value previously dereferenced in {1}

A value is checked here to see whether it is null, but this value can't be null because it was previously dereferenced and if it were null a null pointer exception would have occurred at the earlier dereference. Essentially, this code and the previous dereference disagree as to whether this value is allowed to be null. Either the check is redundant or the previous dereference is erroneous.

]]>

Redundant nullcheck of value known to be null Redundant nullcheck of {2} which is known to be null in {1}

This method contains a redundant check of a known null value against the constant null.

]]>

Redundant nullcheck of value known to be non-null Redundant nullcheck of {2}, which is known to be non-null in {1}

This method contains a redundant check of a known non-null value against the constant null.

]]>

Redundant comparison of two null values Redundant comparison of two null values in {1}

This method contains a redundant comparison of two references known to both be definitely null.

]]>

Redundant comparison of non-null value to null Redundant comparison of non-null value to null in {1}

This method contains a reference known to be non-null with another reference known to be null.

]]>

Redundant comparison to null of previously checked value Redundant comparison to null of previously checked {2} in {1}

This method contains a redundant comparison of a reference value to null. Two types of redundant comparison are reported:

Both values compared are definitely null
One value is definitely null and the other is definitely not null

This particular warning generally indicates that a value known not to be null was checked against null. While the check is not necessary, it may simply be a case of defensive programming.

]]>

Method does not release lock on all paths {1} does not release lock on all paths

This method acquires a JSR-166 (java.util.concurrent) lock, but does not release it on all paths out of the method. In general, the correct idiom for using a JSR-166 lock is:

    Lock l = ...;
    l.lock();
    try {
        // do something
    } finally {
        l.unlock();
    }

]]>

Method does not release lock on all exception paths {1} does not release lock on all exception paths

This method acquires a JSR-166 (java.util.concurrent) lock, but does not release it on all exception paths out of the method. In general, the correct idiom for using a JSR-166 lock is:

    Lock l = ...;
    l.lock();
    try {
        // do something
    } finally {
        l.unlock();
    }

]]>

Suspicious reference comparison Suspicious comparison of {2} references in {1}

This method compares two reference values using the == or != operator, where the correct way to compare instances of this type is generally with the equals() method. Examples of classes which should generally not be compared by reference are java.lang.Integer, java.lang.Float, etc.

]]>

Using pointer equality to compare different types Using pointer equality to compare a {2} with a {3} in {1}

This method uses using pointer equality to compare two references that seem to be of different types. The result of this comparison will always be false at runtime.

]]>

Call to equals() comparing different types Call to equals() comparing different types in {1}

This method calls equals(Object) on two references of different class types with no common subclasses. Therefore, the objects being compared are unlikely to be members of the same class at runtime (unless some application classes were not analyzed, or dynamic class loading can occur at runtime). According to the contract of equals(), objects of different classes should always compare as unequal; therefore, according to the contract defined by java.lang.Object.equals(Object), the result of this comparison will always be false at runtime.

]]>

Call to equals() comparing different interface types Call to equals() comparing different interface types in {1}

This method calls equals(Object) on two references of unrelated interface types, where neither is a subtype of the other, and there are no known non-abstract classes which implement both interfaces. Therefore, the objects being compared are unlikely to be members of the same class at runtime (unless some application classes were not analyzed, or dynamic class loading can occur at runtime). According to the contract of equals(), objects of different classes should always compare as unequal; therefore, according to the contract defined by java.lang.Object.equals(Object), the result of this comparison will always be false at runtime.

]]>

Call to equals() comparing unrelated class and interface Call to equals() comparing unrelated class and interface in {1}

This method calls equals(Object) on two references, one of which is a class and the other an interface, where neither the class nor any of its non-abstract subclasses implement the interface. Therefore, the objects being compared are unlikely to be members of the same class at runtime (unless some application classes were not analyzed, or dynamic class loading can occur at runtime). According to the contract of equals(), objects of different classes should always compare as unequal; therefore, according to the contract defined by java.lang.Object.equals(Object), the result of this comparison will always be false at runtime.

]]>

Call to equals() with null argument Call to equals() with null argument in {1}

This method calls equals(Object), passing a null value as the argument. According to the contract of the equals() method, this call should always return false.

]]>

Mismatched wait() Mismatched wait() in {1}

This method calls Object.wait() without obviously holding a lock on the object. Calling wait() without a lock held will result in an IllegalMonitorStateException being thrown.

]]>

Mismatched notify() Mismatched notify() in {1}

This method calls Object.notify() or Object.notifyAll() without obviously holding a lock on the object. Calling notify() or notifyAll() without a lock held will result in an IllegalMonitorStateException being thrown.

]]>

Self assignment of local variable Self assignment of local variable in {1}

This method contains a self assignment of a local variable; e.g.

  public void foo() {
    int x = 3;
    x = x;
  }

Such assignments are useless, and may indicate a logic error or typo.

]]>

Self assignment of field Self assignment of field {2.givenClass} in {1}

This method contains a self assignment of a field; e.g.

  int x;
  public void foo() {
    x = x;
  }

Such assignments are useless, and may indicate a logic error or typo.

]]>

Double assignment of field Double assignment of field {2.givenClass} in {1}

This method contains a double assignment of a field; e.g.

  int x,y;
  public void foo() {
    x = x = 17;
  }

Assigning to a field twice is useless, and may indicate a logic error or typo.

]]>

Double assignment of local variable Double assignment of {2} in {1}

This method contains a double assignment of a local variable; e.g.

  public void foo() {
    int x,y;
    x = x = 17;
  }

Assigning the same value to a variable twice is useless, and may indicate a logic error or typo.

]]>

Nonsensical self computation involving a field (e.g., x & x) Nonsensical self computation of {2.givenClass} with itself {1}

This method performs a nonsensical computation of a field with another reference to the same field (e.g., x&x or x-x). Because of the nature of the computation, this operation doesn't seem to make sense, and may indicate a typo or a logic error. Double check the computation.

]]>

Nonsensical self computation involving a variable (e.g., x & x) Nonsensical self computation of {2} with itself {1}

This method performs a nonsensical computation of a local variable with another reference to the same variable (e.g., x&x or x-x). Because of the nature of the computation, this operation doesn't seem to make sense, and may indicate a typo or a logic error. Double check the computation.

]]>

Self comparison of field with itself Self comparison of {2.givenClass} with itself {1}

This method compares a field with itself, and may indicate a typo or a logic error. Make sure that you are comparing the right things.

]]>

Self comparison of value with itself Self comparison of {2} with itself {1}

This method compares a local variable with itself, and may indicate a typo or a logic error. Make sure that you are comparing the right things.

]]>

Double.longBitsToDouble invoked on an int Double.longBitsToDouble invoked on an int in {1}

The Double.longBitsToDouble method is invoked, but a 32 bit int value is passed as an argument. This almostly certainly is not intended and is unlikely to give the intended result.

]]>

Random object created and used only once Random object created and used only once in {1}

This code creates a java.util.Random object, uses it to generate one random number, and then discards the Random object. This produces mediocre quality random numbers and is inefficient. If possible, rewrite the code so that the Random object is created once and saved, and each time a new random number is required invoke a method on the existing Random object to obtain it.

If it is important that the generated Random numbers not be guessable, you must not create a new Random for each random number; the values are too easily guessable. You should strongly consider using a java.security.SecureRandom instead (and avoid allocating a new SecureRandom for each random number needed).

]]>

Bad attempt to compute absolute value of signed 32-bit random integer Bad attempt to compute absolute value of signed 32-bit random integer in {1}

This code generates a random signed integer and then computes the absolute value of that random integer. If the number returned by the random number generator is Integer.MIN_VALUE, then the result will be negative as well (since Math.abs(Integer.MIN_VALUE) == Integer.MIN_VALUE).

]]>

Bad attempt to compute absolute value of signed 32-bit hashcode Bad attempt to compute absolute value of signed 32-bit hashcode in {1}

This code generates a hashcode and then computes the absolute value of that hashcode. If the hashcode is Integer.MIN_VALUE, then the result will be negative as well (since Math.abs(Integer.MIN_VALUE) == Integer.MIN_VALUE).

]]>

Remainder of 32-bit signed random integer Remainder of 32-bit signed random integer computed in {1}

This code generates a random signed integer and then computes the remainder of that value modulo another value. Since the random number can be negative, the result of the remainder operation can also be negative. Be sure this is intended, and strongly consider using the Random.nextInt(int) method instead.

]]>

Remainder of hashCode could be negative Remainder of hashCode could be negative in {1}

This code computes a hashCode, and then computes the remainder of that value modulo another value. Since the hashCode can be negative, the result of the remainder operation can also be negative.

Assuming you want to ensure that the result of your computation is nonnegative, you may need to change your code. If you know the divisor is a power of 2, you can use a bitwise and operator instead (i.e., instead of using x.hashCode()%n, use x.hashCode()&(n-1). This is probably faster than computing the remainder as well. If you don't know that the divisor is a power of 2, take the absolute value of the result of the remainder operation (i.e., use Math.abs(x.hashCode()%n)

]]>

Bad comparison of nonnegative value with negative constant Bad comparison of nonnegative value with {2} in {1}

This code compares a value that is guaranteed to be non-negative with a negative constant.

]]>

Bad comparison of signed byte Bad comparison of signed byte with {2} in {1}

Signed bytes can only have a value in the range -128 to 127. Comparing a signed byte with a value outside that range is vacuous and likely to be incorrect. To convert a signed byte b to an unsigned value in the range 0..255, use 0xff & b

]]>

Vacuous comparison of integer value Vacuous comparison of integer value {1}

There is an integer comparison that always returns the same value (e.g., x <= Integer.MAX_VALUE).

]]>

Integer remainder modulo 1 Integer remainder modulo 1 computed in {1}

Any expression (exp % 1) is guaranteed to always return zero. Did you mean (exp & 1) or (exp % 2) instead?

]]>

Bitwise OR of signed byte value Bitwise OR of signed byte value computed in {1}

Loads a value from a byte array and performs a bitwise OR with that value. Values loaded from a byte array are sign extended to 32 bits before any any bitwise operations are performed on the value. Thus, if b[0] contains the value 0xff, and x is initially 0, then the code ((x << 8) | b[0]) will sign extend 0xff to get 0xffffffff, and thus give the value 0xffffffff as the result.

In particular, the following code for packing a byte array into an int is badly wrong:


int result = 0;
for(int i = 0; i < 4; i++) 
  result = ((result << 8) | b[i]);

The following idiom will work instead:


int result = 0;
for(int i = 0; i < 4; i++) 
  result = ((result << 8) | (b[i] &s; 0xff));

]]>

Incompatible bit masks Incompatible bit masks yield a constant result in {1}

This method compares an expression of the form (a & C) to D, which will always compare unequal due to the specific values of constants C and D. This may indicate a logic error or typo.

]]>

Check for sign of bitwise operation Check for sign of bitwise operation in {1}

This method compares an expression such as

((event.detail & SWT.SELECTED) > 0)

. Using bit arithmetic and then comparing with the greater than operator can lead to unexpected results (of course depending on the value of SWT.SELECTED). If SWT.SELECTED is a negative number, this is a candidate for a bug. Even when SWT.SELECTED is not negative, it seems good practice to use '!= 0' instead of '> 0'.

Boris Bokowski

]]>

Check for sign of bitwise operation Check for sign of bitwise operation in {1}

This method compares an expression such as

((event.detail & SWT.SELECTED) > 0)

Boris Bokowski

]]>

Check to see if ((...) & 0) == 0 Check to see if ((...) & 0) == 0 in {1}

This method compares an expression of the form (a & 0) to 0, which will always compare equal. This may indicate a logic error or typo.

]]>

Incompatible bit masks Incompatible bit masks yield a constant result in {1}

This method compares an expression of the form (a | C) to D. which will always compare unequal due to the specific values of constants C and D. This may indicate a logic error or typo.

Typically, this bug occurs because the code wants to perform a membership test in a bit set, but uses the bitwise OR operator ("|") instead of bitwise AND ("&").

]]>

Incorrect lazy initialization of instance field Incorrect lazy initialization of instance field {2} in {1}

This method contains an unsynchronized lazy initialization of a non-volatile field. Because the compiler or processor may reorder instructions, threads are not guaranteed to see a completely initialized object, if the method can be called by multiple threads. You can make the field volatile to correct the problem. For more information, see the Java Memory Model web site.

]]>

Incorrect lazy initialization of static field Incorrect lazy initialization of static field {2} in {1}

This method contains an unsynchronized lazy initialization of a non-volatile static field. Because the compiler or processor may reorder instructions, threads are not guaranteed to see a completely initialized object, if the method can be called by multiple threads. You can make the field volatile to correct the problem. For more information, see the Java Memory Model web site.

]]>

Incorrect lazy initialization and update of static field Incorrect lazy initialization and update of static field {2} in {1}

This method contains an unsynchronized lazy initialization of a static field. After the field is set, the object stored into that location is further accessed. The setting of the field is visible to other threads as soon as it is set. If the futher accesses in the method that set the field serve to initialize the object, then you have a very serious multithreading bug, unless something else prevents any other thread from accessing the stored object until it is fully initialized.

]]>

Synchronization performed on java.util.concurrent Lock Synchronization performed on java.util.concurrent Lock in {1}

This method performs synchronization on an implementation of java.util.concurrent.locks.Lock. You should use the lock() and unlock() methods instead.

]]>

Private method is never called Private method {1} is never called

This private method is never called. Although it is possible that the method will be invoked through reflection, it is more likely that the method is never used, and should be removed.

]]>

Uncallable method defined in anonymous class Uncallable method {1} defined in anonymous class

This anonymous class defined a method that is not directly invoked and does not override a method in a superclass. Since methods in other classes cannot directly invoke methods declared in an anonymous class, it seems that this method is uncallable. The method might simply be dead code, but it is also possible that the method is intended to override a method declared in a superclass, and due to an typo or other error the method does not, in fact, override the method it is intended to.

]]>

Method may fail to close database resource {1} may fail to close {2.excludingPackage}

The method creates a database resource (such as a database connection or row set), does not assign it to any fields, pass it to other methods, or return it, and does not appear to close the object on all paths out of the method. Failure to close database resources on all paths out of a method may result in poor performance, and could cause the application to have problems communicating with the database.

]]>

Method may fail to close database resource on exception {1} may fail to close database resource on exception

The method creates a database resource (such as a database connection or row set), does not assign it to any fields, pass it to other methods, or return it, and does not appear to close the object on all exception paths out of the method. Failure to close database resources on all paths out of a method may result in poor performance, and could cause the application to have problems communicating with the database.

]]>

Method concatenates strings using + in a loop Method {1} concatenates strings using + in a loop

The method seems to be building a String using concatenation in a loop. In each iteration, the String is converted to a StringBuffer/StringBuilder, appended to, and converted back to a String. This can lead to a cost quadratic in the number of iterations, as the growing string is recopied in each iteration.

Better performance can be obtained by using a StringBuffer (or StringBuilder in Java 1.5) explicitly.

For example:

  // This is bad
  String s = "";
  for (int i = 0; i < field.length; ++i) {
    s = s + field[i];
  }

  // This is better
  StringBuffer buf = new StringBuffer();
  for (int i = 0; i < field.length; ++i) {
    buf.append(field[i]);
  }
  String s = buf.toString();

]]>

Method uses toArray() with zero-length array argument Method {1} uses Collection.toArray() with zero-length array argument

This method uses the toArray() method of a collection derived class, and passes in a zero-length prototype array argument. It is more efficient to use myCollection.toArray(new Foo[myCollection.size()]) If the array passed in is big enough to store all of the elements of the collection, then it is populated and returned directly. This avoids the need to create a second array (by reflection) to return as the result.

]]>

JUnit assertion in run method will not be noticed by JUnit JUnit assertion in {1} will not be noticed by JUnit

A JUnit assertion is performed in a run method. Failed JUnit assertions just result in exceptions being thrown. Thus, if this exception occurs in a thread other than the thread that invokes the test method, the exception will terminate the thread but not result in the test failing.

]]>

TestCase implements setUp but doesn't call super.setUp() TestCase {0} implements setUp but doesn't call super.setUp()

Class is a JUnit TestCase and implements the setUp method. The setUp method should call super.setUp(), but doesn't.

]]>

TestCase implements tearDown but doesn't call super.tearDown() TestCase {0} implements tearDown but doesn't call super.tearDown()

Class is a JUnit TestCase and implements the tearDown method. The tearDown method should call super.tearDown(), but doesn't.

]]>

TestCase implements a non-static suite method TestCase {0} implements a non-static suite method

Class is a JUnit TestCase and implements the suite() method. The suite method should be declared as being static, but isn't.

]]>

TestCase declares a bad suite method Bad declaration for suite method in {0}

Class is a JUnit TestCase and defines a suite() method. However, the suite method needs to be declared as either

public static junit.framework.Test suite()

public static junit.framework.TestSuite suite()

]]>

TestCase has no tests TestCase {0} has no tests

Class is a JUnit TestCase but has not implemented any test methods

]]>

Class overrides a method implemented in super class Adapter wrongly Class {0} overrides a method {1} implemented in super class Adapter wrongly

This method overrides a method found in a parent class, where that class is an Adapter that implements a listener defined in the java.awt.event or javax.swing.event package. As a result, this method will not get called when the event occurs.

]]>

Method attempts to access a result set field with index 0 Method {1} attempts to access a result set field with index 0

A call to getXXX or updateXXX methods of a result set was made where the field index is 0. As ResultSet fields start at index 1, this is always a mistake.

]]>

Method attempts to access a result set field with index 0 Method {1} attempts to access a result set field with index 0

A call to getXXX or updateXXX methods of a result set was made where the field index is 0. As ResultSet fields start at index 1, this is always a mistake.

]]>

Method attempts to access a prepared statement parameter with index 0 Method {1} attempts to access a prepared statement parameter with index 0

A call to a setXXX method of a prepared statement was made where the parameter index is 0. As parameter indexes start at index 1, this is always a mistake.

]]>

Unnecessary type check done using instanceof operator Method {1} does an unnecessary type check using instanceof operator when it can be determined statically

Type check performed using the instanceof operator where it can be statically determined whether the object is of the type requested.

]]>

Bad Applet Constructor relies on uninitialized AppletStub Bad Applet Constructor relies on uninitialized AppletStub

This constructor calls methods in the parent Applet that rely on the AppletStub. Since the AppletStub isn't initialized until the init() method of this applet is called, these methods will not perform correctly.

]]>

equals() used to compare array and nonarray {1} uses equals to compare an array and nonarray

This method invokes the .equals(Object o) to compare an array and a reference that doesn't seem to be an array. If things being compared are of different types, they are guaranteed to be unequal and the comparison is almost certainly an error. Even if they are both arrays, the equals method on arrays only determines of the two arrays are the same object. To compare the contents of the arrays, use java.util.Arrays.equals(Object[], Object[]).

]]>

Invocation of equals() on an array, which is equivalent to == {1} invokes equals() on an array, which is equivalent to ==

This method invokes the .equals(Object o) method on an array. Since arrays do not override the equals method of Object, calling equals on an array is the same as comparing their addresses. To compare the contents of the arrays, use java.util.Arrays.equals(Object[], Object[]).

]]>

Calls to equals on a final class that doesn't override Object's version Calls to equals on a final class that doesn't override Object's version

This method invokes the .equals(Object o) method on a final class that doesn't override the equals method in the Object class, effectively making the equals method test for sameness, like ==. It is good to use the .equals method, but you should consider adding an .equals method in this class.

[Bill Pugh]: Sorry, but I strongly disagree that this should be a warning, and I think your code is just fine. Users of your code shouldn't care how you've implemented equals(), and they should never depend on == to compare instances, since that bypasses the libraries ability to control how objects are compared.

]]>

Unneeded use of currentThread() call, to call interrupted() Method {1} makes an unneeded call to currentThread() just to call interrupted()

This method invokes the Thread.currentThread() call, just to call the interrupted() method. As interrupted() is a static method, is more simple and clear to use Thread.interrupted().

]]>

Static Thread.interrupted() method invoked on thread instance {1} invokes static Thread.interrupted() method on thread instance

This method invokes the Thread.interrupted() method on a Thread object that appears to be a Thread object that is not the current thread. As the interrupted() method is static, the interrupted method will be called on a different object than the one the author intended.

]]>

A parameter is dead upon entry to a method but overwritten The parameter {2} to {1} is dead upon entry but overwritten

The initial value of this parameter is ignored, and the parameter is overwritten here. This often indicates a mistaken belief that the write to the parameter will be conveyed back to the caller.

]]>

Dead store to local variable Dead store to {2} in {1}

This instruction assigns a value to a local variable, but the value is not read or used in any subsequent instruction. Often, this indicates an error, because the value computed is never used.

Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.

]]>

Useless assignment in return statement Useless assignment in return from {1}

This statement assigns to a local variable in a return statement. This assignment has effect. Please verify that this statement does the right thing.

]]>

Dead store of class literal Dead store of {3}.class in {1}

This instruction assigns a class literal to a variable and then never uses it. The behavior of this differs in Java 1.4 and in Java 5. In Java 1.4 and earlier, a reference to Foo.class would force the static initializer for Foo to be executed, if it has not been executed already. In Java 5 and later, it does not.

See Sun's article on Java SE compatibility for more details and examples, and suggestions on how to force class initialization in Java 5.

]]>

Dead store of null to local variable Dead store of null to {2} in {1}

The code stores null into a local variable, and the stored value is not read. This store may have been introduced to assist the garbage collector, but as of Java SE 6.0, this is no longer needed or useful.

]]>

Method defines a variable that obscures a field Method {1} defines a variable that obscures field {2.givenClass}

This method defines a local variable with the same name as a field in this class or a superclass. This may cause the method to read an uninitialized value from the field, leave the field uninitialized, or both.

]]>

Class defines field that masks a superclass field Field {1.givenClass} masks field in superclass {2.class}

This class defines a field with the same name as a visible instance field in a superclass. This is confusing, and may indicate an error if methods update or access one of the fields when they wanted the other.

]]>

Inefficient use of keySet iterator instead of entrySet iterator Method {1} makes inefficient use of keySet iterator instead of entrySet iterator

This method accesses the value of a Map entry, using a key that was retrieved from a keySet iterator. It is more efficient to use an iterator on the entrySet of the map, to avoid the Map.get(key) lookup.

]]>

Needless instantiation of class that only supplies static methods Method {1} needlessly instantiates a class that only supplies static methods

This class allocates an object that is based on a class that only supplies static methods. This object does not need to be created, just access the static methods directly using the class name as a qualifier.

]]>

Exception is caught when Exception is not thrown Exception is caught when Exception is not thrown in {1}

This method uses a try-catch block that catches Exception objects, but Exception is not thrown within the try block, and RuntimeException is not explicitly caught. It is a common bug pattern to say try { ... } catch (Exception e) { something } as a shorthand for catching a number of types of exception each of whose catch blocks is identical, but this construct also accidentally catches RuntimeException as well, masking potential bugs.

]]>

Doomed test for equality to NaN Doomed test for equality to NaN in {1}

This code checks to see if a floating point value is equal to the special Not A Number value (e.g., if (x == Double.NaN)). However, because of the special semantics of NaN, no value is equal to Nan, including NaN. Thus, x == Double.NaN always evaluates to false. To check to see if a value contained in x is the special Not A Number value, use Double.isNaN(x) (or Float.isNaN(x) if x is floating point precision).

]]>

Test for floating point equality Test for floating point equality in {1}

This operation compares two floating point values for equality. Because floating point calculations may involve rounding, calculated float and double values may not be accurate. For values that must be precise, such as monetary values, consider using a fixed-precision type such as BigDecimal. For values that need not be precise, consider comparing for equality within some range, for example: if ( Math.abs(x - y) < .0000001 ). See the Java Language Specification, section 4.2.4.

]]>

Method calls static Math class method on a constant value Method calls static Math class method on a constant value

This method uses a static method from java.lang.Math on a constant value. This method's result in this case, can be determined statically, and is faster and sometimes more accurate to just use the constant. Methods detected are:

Method	Parameter
abs	-any-
acos	0.0 or 1.0
asin	0.0 or 1.0
atan	0.0 or 1.0
atan2	0.0
cbrt	0.0 or 1.0
ceil	-any-
cos	0.0
cosh	0.0
exp	0.0 or 1.0
expm1	0.0
floor	-any-
log	0.0 or 1.0
log10	0.0 or 1.0
rint	-any-
round	-any-
sin	0.0
sinh	0.0
sqrt	0.0 or 1.0
tan	0.0
tanh	0.0
toDegrees	0.0 or 1.0
toRadians	0.0

]]>

Test for circular dependencies among classes Class {0} has a circular dependency with other classes

This class has a circular dependency with other classes. This makes building these classes difficult, as each is dependent on the other to build correctly. Consider using interfaces to break the hard dependency.

]]>

Class implements same interface as superclass Class {0} implements same interface as superclass

This class declares that it implements an interface that is also implemented by a superclass. This is redundant because once a superclass implements an interface, all subclasses by default also implement this interface. It may point out that the inheritance hierarchy has changed since this class was created, and consideration should be given to the ownership of the interface's implementation.

]]>

Class extends Struts Action class and uses instance variables Class {0} extends Struts Action class and uses instance variables

This class extends from a Struts Action class, and uses an instance member variable. Since only one instance of a struts Action class is created by the Struts framework, and used in a multithreaded way, this paradigm is highly discouraged and most likely problematic. Consider only using method local variables. Only instance fields that are written outside of a monitor are reported.

]]>

Class extends Servlet class and uses instance variables Class {0} extends Servlet class and uses instance variables

This class extends from a Servlet class, and uses an instance member variable. Since only one instance of a Servlet class is created by the J2EE framework, and used in a multithreaded way, this paradigm is highly discouraged and most likely problematic. Consider only using method local variables.

]]>

Class exposes synchronization and semaphores in its public interface Class {0} exposes synchronization and semaphores in its public interface

This class uses synchronization along with wait(), notify() or notifyAll() on itself (the this reference). Client classes that use this class, may, in addition, use an instance of this class as a synchronizing object. Because two classes are using the same object for synchronization, Multithread correctness is suspect. You should not synchronize nor call semaphore methods on a public reference. Consider using a internal private member variable to control synchronization.

]]>

Result of integer multiplication cast to long Result of integer multiplication cast to long in {1}

This code performs integer multiply and then converts the result to a long, as in:


 
	long convertDaysToMilliseconds(int days) { return 1000*3600*24*days; }

If the multiplication is done using long arithmetic, you can avoid the possibility that the result will overflow. For example, you could fix the above code to:


 
	long convertDaysToMilliseconds(int days) { return 1000L*3600*24*days; }


 
	static final long MILLISECONDS_PER_DAY = 24L*3600*1000;
	long convertDaysToMilliseconds(int days) { return days * MILLISECONDS_PER_DAY; }

]]>

int value cast to float and then passed to Math.round int value cast to float and then passed to Math.round in {1}

This code converts an int value to a float precision floating point number and then passing the result to the Math.round() function, which returns the int/long closest to the argument. This operation should always be a no-op, since the converting an integer to a float should give a number with no fractional part. It is likely that the operation that generated the value to be passed to Math.round was intended to be performed using floating point arithmetic.

]]>

int value cast to double and then passed to Math.ceil int value cast to double and then passed to Math.ceil in {1}

This code converts an int value to a double precision floating point number and then passing the result to the Math.ceil() function, which rounds a double to the next higher integer value. This operation should always be a no-op, since the converting an integer to a double should give a number with no fractional part. It is likely that the operation that generated the value to be passed to Math.ceil was intended to be performed using double precision floating point arithmetic.

]]>

int division result cast to double or float int division result cast to double or float in {1}

This code casts the result of an integer division operation to double or float. Doing division on integers truncates the result to the integer value closest to zero. The fact that the result was cast to double suggests that this precision should have been retained. What was probably meant was to cast one or both of the operands to double before performing the division. Here is an example:

int x = 2;
int y = 5;
// Wrong: yields result 0.0
double value1 =  x / y;

// Right: yields result 0.4
double value2 =  x / (double) y;

]]>

Store of non serializable object into HttpSession Store of non serializable {2} into HttpSession in {1}

This code seems to be storing a non-serializable object into an HttpSession. If this session is passivated or migrated, an error will result.

]]>

Non serializable object written to ObjectOutput Non serializable {2} written to ObjectOutput in {1}

This code seems to be passing a non-serializable object to the ObjectOutput.writeObject method. If the object is, indeed, non-serializable, an error will result.

]]>

Number of format-string arguments does not correspond to number of placeholders Format-string method {2} called with format string "{3}" wants {4} arguments but is given {5} in {1}

A format-string method with a variable number of arguments is called, but the number of arguments passed does not match with the number of % placeholders in the format string. This is probably not what the author intended.

]]>

Primitive array passed to function expecting a variable number of object arguments {2} passed to varargs method {3} in {1}

This code passes a primitive array to a function that takes a variable number of object arguments. This creates an array of length one to hold the primitive array and passes it to the function.

]]>

Equals method should not assume anything about the type of its argument Equals method for {0} assumes the argument is of type {0.givenClass}

The equals(Object o) method shouldn't make any assumptions about the type of o. It should simply return false if o is not the same type as this.

]]>

Questionable cast to abstract collection Questionable cast from Collection to abstract class {3} in {1}

This code casts a Collection to an abstract collection (such as List, Set, or Map). Ensure that you are guaranteed that the object is of the type you are casting to. If all you need is to be able to iterate through a collection, you don't need to cast it to a Set or List.

]]>

Impossible cast involving primitive array Impossible cast involving primitive array in {1}

This cast will always throw a ClassCastException.

]]>

Impossible cast Impossible cast from {2} to {3} in {1}

This cast will always throw a ClassCastException.

]]>

A known null value is checked to see if it is an instance of a type A known null value is checked to see if it is an instance of {2} in {1}

This instanceof test will always return false, since the value being checked is guaranteed to be null. Although this is safe, make sure it isn't an indication of some misunderstanding or some other logic error.

]]>

A known null value is checked to see if it is an instance of a type A known null value is checked to see if it is an instance of {2} in {1}

]]>

instanceof will always return false instanceof will always return false in {1}, since a {2} can't be a {3}

This instanceof test will always return false. Although this is safe, make sure it isn't an indication of some misunderstanding or some other logic error.

]]>

instanceof will always return true instanceof will always return true in {1}, since all {2} are instances of {3}

This instanceof test will always return true. Although this is safe, make sure it isn't an indication of some misunderstanding or some other logic error.

]]>

Unchecked/unconfirmed cast Unchecked/unconfirmed cast from {2} to {3} in {1}

This cast is unchecked, and not all instances of the type casted from can be cast to the type it is being cast to. Ensure that your program logic ensures that this cast will not fail.

]]>

Questionable cast to concrete collection Questionable cast from {2} to {3} in {1}

This code casts an abstract collection (such as a Collection, List, or Set) to a specific concrete implementation (such as an ArrayList or HashSet). This might not be correct, and it may make your code fragile, since it makes it harder to switch to other concrete implementations at a future point. Unless you have a particular reason to do so, just use the abstract collection class.

]]>

"." used for regular expression "." used for regular expression in {1}

A String function is being invoked and "." is being passed to a parameter that takes a regular expression as an argument. Is this what you intended? For example s.replaceAll(".", "/") will return a String in which every character has been replaced by a / character.

]]>

Invalid syntax for regular expression Invalid syntax for regular expression in {1}

The code here uses a regular expression that is invalid according to the syntax for regular expressions. This statement will throw a PatternSyntaxException when executed.

]]>

File.separator used for regular expression File.separator used for regular expression in {1}

The code here uses File.separator where a regular expression is required. This will fail on Windows platforms, where the File.separator is a backslash, which is interpreted in a regular expression as an escape character. Amoung other options, you can just use File.separatorChar=='\\' & "\\\\" : File.separator instead of File.separator

]]>

Overwritten increment Overwritten increment in {1}

The code performs an increment operation (e.g., i++) and then immediately overwrites it. For example, i = i++ immediately overwrites the incremented value with the original value.

]]>

Unsigned right shift cast to short/byte Unsigned right shift cast to short/byte in {1}

The code performs an unsigned right shift, whose result is then cast to a short or byte, which discards the upper bits of the result. Since the upper bits are discarded, there may be no difference between a signed and unsigned right shift (depending upon the size of the shift).

]]>

Integer shift by an amount not in the range 0..31 Integer shift by {2} in {1}

The code performs an integer shift by a constant amount outside the range 0..31. The effect of this is to use the lower 5 bits of the integer value to decide how much to shift by. This probably isn't want was expected, and it at least confusing.

]]>

Integer multiply of result of integer remainder Integer multiple of result of integer remainder in {1}

The code multiplies the result of an integer remaining by an integer constant. Be sure you don't have your operator precedence confused. For example i % 60 * 1000 is (i % 60) * 1000, not i % (60 * 1000).

]]>

Invocation of toString on an array Invocation of toString on {2} in {1}

The code invokes toString on an array, which will generate a fairly useless result such as [C@16f0472. Consider using Arrays.toString to convert the array into a readable String that gives the contents of the array. See Programming Puzzlers, chapter 3, puzzle 12.

]]>

Invocation of toString on an array Invocation of toString on an array in {1}

The code invokes toString on an (anonymous) array. Calling toString on an array generates a fairly useless result such as [C@16f0472. Consider using Arrays.toString to convert the array into a readable String that gives the contents of the array. See Programming Puzzlers, chapter 3, puzzle 12.

]]>

Computation of average could overflow Computation of average could overflow in {1}

The code computes the average of two integers using either division or signed right shift, and then uses the result as the index of an array. If the values being averaged are very large, this can overflow (resulting in the computation of a negative average). Assuming that the result is intended to be nonnegative, you can use an unsigned right shift instead. In other words, rather that using (low+high)/2, use (low+high) >>> 1

This bug exists in many earlier implementations of binary search and merge sort. Martin Buchholz found and fixed it in the JDK libraries, and Joshua Bloch widely publicized the bug pattern.

]]>

Check for oddness that won't work for negative numbers Check for oddness that won't work for negative numbers in {1}

The code uses x % 2 == 1 to check to see if a value is odd, but this won't work for negative numbers (e.g., (-5) % 2 == -1). If this code is intending to check for oddness, consider using x & 1 == 1, or x % 2 != 0.

]]>

Code contains a hard coded reference to an absolute pathname Hard coded reference to an absolute pathname in {1}

This code constructs a File object using a hard coded to an absolute pathname (e.g., new File("/home/dannyc/workspace/j2ee/src/share/com/sun/enterprise/deployment");

]]>

Bad constant value for month {1} passes a bad month value of {2} to {3}

This code passes a constant month value outside the expected range of 0..11 to a method.

]]>

Invocation of substring(0), which returns the original value {1} invokes substring(0), which returns the original value

This code invokes substring(0) on a String, which returns the original value.

]]>

hasNext method invokes next {1} invokes {3}

The hasNext() method invokes the next() method. This is almost certainly wrong, since the hasNext() method is not supposed to change the state of the iterator, and the next method is supposed to change the state of the iterator.

]]>

Method calls Thread.sleep() with a lock held {1} calls Thread.sleep() with a lock held

This method calls Thread.sleep() with a lock held. This may result in very poor performance and scalability, or a deadlock, since other threads may be waiting to acquire the lock. It is a much better idea to call wait() on the lock, which releases the lock and allows other threads to run.

]]>

Method uses the same code for two branches Method {1} uses the same code for two branches

This method uses the same code to implement two branches of a conditional branch. Check to ensure that this isn't a coding mistake.

]]>

Method uses the same code for two switch clauses Method {1} uses the same code for two switch clauses

This method uses the same code to implement two clauses of a switch statement. This could be a case of duplicate code, but it might also indicate a coding mistake.

]]>

Method accesses a private member variable of owning class Method {1} accesses to a private member variable of owning class

This method of an inner class reads from or writes to a private member variable of the owning class, or calls a private method of the owning class. The compiler must generate a special method to access this private member, causing this to be less efficient. Relaxing the protection of the member variable or method will allow the compiler to treat this as a normal access.

]]>

Method directly allocates a specific implementation of xml interfaces Method {1} directly allocates a specific implementation of xml interfaces

This method allocates a specific implementation of an xml interface. It is preferable to use the supplied factory classes to create these objects so that the implementation can be changed at runtime. See

javax.xml.parsers.DocumentBuilderFactory
javax.xml.parsers.SAXParserFactory
javax.xml.transform.TransformerFactory
org.w3c.dom.Document.createXXXX

for details.

]]>

Method superfluously delegates to parent class method Method {1} superfluously delegates to parent class method

This derived method merely calls the same superclass method passing in the exact parameters received. This method can be removed, as it provides no additional value.

]]>

Abstract Method is already defined in implemented interface Abstract Method {1} is already defined in implemented interface

This abstract method is already defined in an interface that is implemented by this abstract class. This method can be removed, as it provides no additional value.

]]>

Class is final but declares protected field Class {0} is final but declares protected field {1}

This class is declared to be final, but declares fields to be protected. Since the class is final, it can not be derived from, and the use of protected is confusing. The access modifier for the field should be changed to private or public to represent the true use for the field.

]]>

Method assigns boolean literal in boolean expression Method {1} assigns boolean literal in boolean expression

This method assigns a literal boolean value (true or false) to a boolean variable inside an if or while expression. Most probably this was supposed to be a boolean comparison using ==, not an assignment using =.

]]>

Class makes reference to unresolvable class or method Unresolvable reference to {1} by {0}

This class makes a reference to a class or method that can not be resolved using against the libraries it is being analyzed with.

]]>

No relationship between generic parameter and method argument {2} is incompatible with expected argument type {3} in {1}

This call to a generic container's method contains an argument with a different class type from that of the container's parameter. Therefore, it is unlikely that the container contains any objects with the same type as the method argument used here.

]]>

Static Calendar Found static field of type java.util.Calendar in {1}

Even though the JavaDoc does not contain a hint about it, Calendars are inherently unsafe for multihtreaded use. Sharing a single instance across thread boundaries without proper synchronization will result in erratic behavior of the application. Under 1.4 problems seem to surface less often than under Java 5 where you will probably see random ArrayIndexOutOfBoundsExceptions or IndexOutOfBoundsExceptions in sun.util.calendar.BaseCalendar.getCalendarDateFromFixedDate().

You may also experience serialization problems.

Using an instance field is recommended.

For more information on this see Sun Bug #6231579 and Sun Bug #6178997.

]]>

Call to static Calendar Call to method of static java.util.Calendar in {1}

Even though the JavaDoc does not contain a hint about it, Calendars are inherently unsafe for multihtreaded use. The detector has found a call to an instance of Calendar that has been obtained via a static field. This looks suspicous.

For more information on this see Sun Bug #6231579 and Sun Bug #6178997.

]]>

Static DateFormat Found static field of type java.text.DateFormat in {1}

As the JavaDoc states, DateFormats are inherently unsafe for multithreaded use. Sharing a single instance across thread boundaries without proper synchronization will result in erratic behavior of the application.

You may also experience serialization problems.

Using an instance field is recommended.

For more information on this see Sun Bug #6231579 and Sun Bug #6178997.

]]>

Call to static DateFormat Call to method of static java.text.DateFormat in {1}

As the JavaDoc states, DateFormats are inherently unsafe for multithreaded use. The detector has found a call to an instance of DateFormat that has been obtained via a static field. This looks suspicous.

For more information on this see Sun Bug #6231579 and Sun Bug #6178997.

]]>

Value annotated as carrying a type qualifier used where a value that must not carry that qualifier is required Value annotated as carrying type qualifier @{2.excludingPackage} used where a value that must not carry that qualifier is required

A value specified as carrying a type qualifier annotation is consumed in a location or locations requiring that the value not carry that annotation.

More precisely, a value annotated with a type qualifier specifying when=ALWAYS is guaranteed to reach a use or uses where the same type qualifier specifies when=NEVER.

For example, say that @NonNegative is a nickname for the type qualifier annotation @Negative(when=When.NEVER). The following code will generate this warning because the return statement requires a @NonNegative value, but receives one that is marked as @Negative.

public @NonNegative Integer example(@Negative Integer value) {
    return value;
}

]]>

Value annotated as never carrying a type qualifier used where value carrying that qualifier is required Value annotated as never carrying type qualifier @{2.excludingPackage} used where value carrying that qualifier is required

A value specified as not carrying a type qualifier annotation is guaranteed to be consumed in a location or locations requiring that the value does carry that annotation.

More precisely, a value annotated with a type qualifier specifying when=NEVER is guaranteed to reach a use or uses where the same type qualifier specifies when=ALWAYS.

TODO: example

]]>

Value that might not carry a type qualifier reaches a use requiring that type qualifier Value that might not carry the @{2.excludingPackage} annotation reaches a use requiring that annotation

A value that might not carry a type qualifier annotation reaches a use which requires that annotation.

For example, consider the following method:

public @Untainted Object mustReturnUntainted(Object unknown) {
    return unknown;
}

The mustReturnUntainted method is required to return a value carrying the @Untainted annotation, but a value not known to carry that annotation is returned.

]]>

Unknown value reaches a use which forbids values carrying type qualifier annotation Unknown value reaches a use which forbids values carrying the @{2.excludingPackage} annotation

A value which might carry a type qualifier annotation reaches a use which forbids values carrying that annotation.

TODO: example.

]]>

Doomed attempt to append to an object output stream Doomed attempt to append to an object output stream in {1}

This code opens a file in append mode and then wraps the result in an object output stream. This won't allow you to append to an existing object output stream stored in a file. If you want to be able to append to an object output stream, you need to keep the object output stream open.

The only situation in which opening a file in append mode and the writing an object output stream could work is if on reading the file you plan to open it in random access mode and seek to the byte offset where the append started.

TODO: example.

]]>

Sychronization on getClass rather than class literal Sychronization on getClass rather than class literal in {1}

This instance method synchronizes on this.getClass(). If this class is subclassed, subclasses will synchronize on the class object for the subclass, which isn't likely what was intended. For example, consider this code from java.awt.Label:

     private static final String base = "label";
     private static int nameCounter = 0;
     String constructComponentName() {
        synchronized (getClass()) {
            return base + nameCounter++;
        }
     }

Subclasses of Label won't synchronize on the same subclass, giving rise to a datarace. Instead, this code should be synchronizing on Label.class

     private static final String base = "label";
     private static int nameCounter = 0;
     String constructComponentName() {
        synchronized (Label.class) {
            return base + nameCounter++;
        }
     }

Bug pattern contributed by Jason Mehrens

]]>

Analysis skipped Infinite Loop Use of volatile Unsafe inheritance Use of floating point precision Testing prototype and incomplete bug pattern Dubious catching of IllegalMonitorStateException Bad implementation of cloneable idiom Possible atomicity violation Incorrect use of finalizers Checking String equality using == or != Synchronization on updated field (Mutable Lock) Unsynchronized get method, synchronized set method Input/Output problem Initialization circularity Suspicious static initializer Mutable servlet field Inconsistent synchronization Problems with equals() Problems with compareTo() Equal objects must have equal hashcodes API misuse Dubious method used Questionable Boxing of primitive value Uninitialized read of field in constructor Method ignores results of InputStream.read() Naked notify Unconditional wait Method spins on field Possible double check of field Wait not in loop Using notify() rather than notifyAll() Dropped or ignored exception Method invokes run() Incorrect definition of Iterator Serializable class with no Version ID Incorrect definition of Serializable class Class's writeObject() method is synchronized but nothing else is Class's readObject() method is synchronized Constructor invokes Thread.start() Mutable static field Method returning array may expose internal representation Confusing method name Unread field should be static Unused field Unread field Unwritten field Inner class could be made static Wait with two locks held Bad use of return value from method Ambiguous invocation Huge String constants HTTP Response splitting vulnerability Cross site scripting vulnerabilitity Null pointer dereference Stream not closed on all paths Prefer zero length arrays to null to indicate no results Useless control flow Redundant comparison to null Lock not released on all paths Suspicious reference comparison Suspicious equals() comparison Mismatched wait() or notify() Useless self-operation Suspicious integer expression Suspicious bitwise logical expression Unsynchronized Lazy Initialization Synchronization on JSR166 Lock Private method is never called Uncallable method of anonymous class Storing reference to mutable object Suspicious use of non-short-circuit boolean operator Database resource not closed on all paths String concatenation in loop using + operator Inefficient use of collection.toArray(new Foo[0]) Swing coding rules Improperly implemented JUnit TestCase Badly Overridden Adapter Switch case falls through Superfluous instanceof Bad Applet Constructor Use Object Equals Suspicious Thread Interrupted Dead local store Ignored parameter Masked Field Inefficient Map Iterator Instantiated Static Class RuntimeException capture Test for floating point equality Unnecessary Math on constants Circular Dependencies Redundant Interfaces Multithreaded Instance Access Public Semaphores Casting from integer values Regular expressions SQL Problem Potential deadlock or unexpected blocking Possible locking on wrong object Empty Synchronized blocks Questionable for loops Var arg problems Bad casts of object references Questionable integer math Misuse of static fields Violation of net.jcip annotations Dubious method invocation Warning inspired by Josh Bloch's and Neal Gafter's Programming Puzzlers Sleep with lock held J2EE error Duplicate Branches Inefficient Member Access XML Factory Bypass Useless Subclass Method Confused Inheritance Questionable Boolean Assignment Version compatibility issue Use doPrivileged Suspicious calls to generic container methods Static use of type Calendar or DateFormat Inconsistent use of type qualifier annotations