FindBugs Bug DescriptionsThis document lists the standard bug patterns reported by version 0.8.5. Summary
DescriptionsAM: Creates an empty jar file entryThe code calls AM: Creates an empty zip file entryThe code calls BIT: Incompatible bit masksThis 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. BIT: Incompatible bit masksThis method compares an expression of the form (a & 0) to 0, which will always compare equal. This may indicate a logic error or typo. BIT: Incompatible bit masksThis 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 ("&"). BOA: Class overrides a method implemented in super class Adapter wronglyThis 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. BRSA: Method attempts to access a result set field with index 0A 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. CN: Class implements Cloneable but does not define or use clone methodClass implements Cloneable but does not define or use the clone method. CN: clone method does not call super.clone()This class defines a clone() method that does not call super.clone(), and is not final. 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. Co: Covariant compareTo() method definedThis class defines a covariant version of DE: Method might drop exceptionThis 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. DE: Method might ignore exceptionThis 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. Dm: Method invokes System.exit(...)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. EC: Call to equals() with null argumentThis method calls equals(Object), passing a null value as the argument. According to the contract of the equals() method, this call should always return EC: Call to equals() comparing different interface typesThis method calls equals(Object) on two references of unrelated interface types (neither is a subtype of the other). According to the contract of equals(), objects of different classes should always compare as unequal. Note that it is possible that the program contains classes that implement both interfaces, so the comparison may be valid. However, it is worth inspecting closely. EC: Call to equals() comparing different typesThis method calls equals(Object) on two references of different types. According to the contract of equals(), objects of different classes should always compare as unequal; therefore, it is likely that the result of this comparision will always be false at runtime. ES: Comparison of String objects using == or !=This code compares Eq: Covariant equals() method definedThis class defines a covariant version of Eq: Covariant equals() method defined, Object.equals(Object) inheritedThis class defines a covariant version of the FI: Explicit invocation of finalizerThis method contains an explicit invocation of the FI: Finalizer does not call superclass finalizerThis FI: Finalizer nullifies superclass finalizerThis empty HE: Class defines equals() but not hashCode()This class overrides HE: Class defines equals() and uses Object.hashCode()This class overrides 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 HE: Class defines hashCode() but not equals()This class defines a HE: Class defines hashCode() and uses Object.equals()This class defines a HE: Class inherits equals() and uses Object.hashCode()This class inherits 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 IC: Initialization circularityA 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. IJU: TestCase 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. IMSE: Dubious catching of IllegalMonitorStateExceptionIllegalMonitorStateException 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). It: Iterator next() method can't throw NoSuchElement exceptionThis class implements the MF: Class defines field that obscures a superclass fieldThis 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. MF: Method defines a variable that obscures a fieldThis 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. MWN: Mismatched notify()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 MWN: Mismatched wait()This method calls Object.wait() without obviously holding a lock on the object. Calling wait() without a lock held will result in an NP: Null pointer dereference in methodA null pointer is dereferenced here. This will lead to a NP: Null pointer dereference in method on exception pathA pointer which is null on an exception path is dereferenced here. This will lead to a Also note that FindBugs considers the default case of a switch statement to be an exception path, since the default case is often infeasible. NP: Possible null pointer dereference in methodA reference value dereferenced here might be null at runtime. This may lead to a NP: Possible null pointer dereference in method on exception pathA reference value which is null on some exception control path is dereferenced here. This may lead to a Also note that FindBugs considers the default case of a switch statement to be an exception path, since the default case is often infeasible. NS: Questionable use of non-short-circuit logicThis 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. Nm: Class defines equal(); should it be equals()?This class defines a method Nm: Confusing method namesThe referenced methods have names that differ only by capitalization. Nm: Confusing method nameThis method has the same name as the superclass of the class it is defined in. Nm: Class defines hashcode(); should it be hashCode()?This class defines a method called Nm: Class defines tostring(); should it be toString()?This class defines a method called Nm: Very confusing method namesThe referenced methods have names that differ only by capitalization. ODR: Method may fail to close database resourceThe 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. ODR: Method may fail to close database resource on exceptionThe 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. OS: Method may fail to close streamThe 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 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 OS: Method may fail to close stream on exceptionThe 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 PZLA: Consider returning a zero length array rather than nullIt 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 otherhand, using null to indicate "there is no answer to this question", then it is probably appropriate. For example, RC: Suspicious reference comparisonThis 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. RCN: Redundant comparision to null of previously checked valueThis method contains a redundant comparison of a reference value to null. Two types of redundant comparison are reported:
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. RCN: Redundant comparison to nullThis method contains a redundant comparison of a reference value to null. Two types of redundant comparison are reported:
This particular warning represents two specific kinds of redundant comparisions:
RR: Method ignores results of InputStream.read()This method ignores the return value of one of the variants of RR: Method ignores results of InputStream.skip()This method ignores the return value of RV: Method ignores return valueThe return value of this method should be checked. SA: Self assignment of fieldThis 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. SI: Static initializer for class creates instance before all static final fields assignedThe class's static initializer creates an instance of the class before all of the static final fields are assigned. SIO: Unnecessary type check done using instanceof operatorType check performed using the instanceof operator where it can be statically determined whether the object is of the type requested. SW: Certain swing methods should only be invoked from the 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. Se: Non-transient non-serializable instance field in serializable classThis Serializable class defines a non-primitive instance field which is neither transient, Serializable, or Se: serialVersionUID isn't finalThis class defines a Se: serialVersionUID isn't longThis class defines a Se: serialVersionUID isn't staticThis class defines a Se: Class is Serializable but its superclass doesn't define a void constructorThis class implements the Se: Class is Externalizable but doesn't define a void constructorThis class implements the SnVI: Class is Serializable, but doesn't define serialVersionUIDThis class implements the UCF: Useless control flow in methodThis method contains a useless control flow statement. Often, this is caused by inadvertently using an empty statement as the body of an if (argv.length == 1); System.out.println("Hello, " + argv[0]); UI: Usage of GetResource may be unsafe if class is extendedCalling UR: Uninitialized read of field in constructorThis 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. UwF: Unwritten fieldThis 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. EI: Method may expose internal representation by returning reference to mutable objectReturning 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. FI: Finalizer should be protected, not publicA class's MS: Method may expose internal static state by storing a mutable object into a static fieldThis 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. MS: Field isn't final and can't be protected from malicious codeA 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. MS: Public static method may expose internal representation by returning arrayA 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. MS: Field should be both final and package protectedA 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. MS: Field is a mutable arrayA 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. MS: Field is a mutable HashtableA 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. MS: Field should be moved out of an interface and made package protectedA 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. MS: Field should be package protectedA mutable static field could be changed by malicious code or by accident. The field could be made package protected to avoid this vulnerability. MS: Field isn't final but should beA 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. 2LW: Wait with two locks heldWaiting 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. DC: Possible double check of fieldThis 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. IS2: Inconsistent synchronizationThe fields of this class appear to be accessed inconsistently with respect to synchronization. This bug report indicates that the bug pattern detector judged that
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. This description refers to the "IS2" version of the pattern detector, which has more accurate ways of detecting locked vs. unlocked accesses than the older "IS" detector. LI: Incorrect lazy initialization of static fieldThis 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. ML: Method synchronizes on an updated fieldThis method synchronizes on an object references from a mutable field. This is unlikely to have useful semantics, since different threads may be synchronizing on different objects. NN: Naked notify in methodA call to 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. No: Using notify() rather than notifyAll() in methodThis method calls RS: Class's readObject() method is synchronizedThis serializable class defines a Ru: Invokes run on a thread (did you mean to start it instead?)This method explicitly invokes SC: Constructor invokes Thread.start()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. SP: Method spins on fieldThis 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). UG: Unsynchronized get method, synchronized set methodThis 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. UW: Unconditional wait in methodThis method contains a call to VO: A volatile reference to an array doesn't treat the array elements as volatileThis 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). WS: Class's writeObject() method is synchronized but nothing else isThis class has a Wa: Wait not in loop in methodThis method contains a call to Dm: Method invokes dubious Boolean constructor; use Boolean.valueOf(...) insteadCreating new instances of Dm: Explicit garbage collection; extremely dubious except in benchmarking codeCode 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. Dm: Method invokes dubious new String(String) constructor; just use the argumentUsing the Dm: Method invokes dubious String.equals(""); use String.length() == 0 insteadAn 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. Dm: Method invokes toString() method on a String; just use the StringCalling Dm: Method invokes dubious new String() constructor; just use ""Creating a new FI: Empty finalizer should be deletedEmpty FI: Finalizer does nothing but call superclass finalizerThe only thing this ITA: Method uses toArray() with zero-length array argumentThis 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. SBSC: Method concatenates strings using + in a loopThe 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 quadractic 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(); SIC: Should be a static inner classThis 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. SIC: Could be refactored into a named static inner classThis 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 requiring refactoring the inner class so that it is a named inner class. SIC: Could be refactored into a static inner classThis 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. SS: Unread field: 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. UPM: Private method is never calledThis 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. UrF: Unread fieldThis field is never read. Consider removing it from the class. UuF: Unused fieldThis field is never used. Consider removing it from the class.
|
扫一扫
264
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
