Findbugs缺陷等级对照表

1、FindBugs Bug DescriptionsThis document lists the standard bug patterns reported by version .Summary序号等级DescriptionCategory14AEC: Call to equals() with null argument调用Equal方法的参数为空Correctness15AEC: Call to equals() comparing different interface types 调用Equal方法去比较不同的接口类型Correctness16AEC: Call to equals

2、() comparing different types调用Equal方法去比较不同的数据类型Correctness17AES: Comparison of String objects using = or !=使用= 或者 != 去比较字符串或对象Correctness29BIJU: TestCase implements setUp but doesn't call super.setUp()测试实例实现了setUp（）但没有调用super.setUp（）Correctness36ANP: Null pointer dereference in method方法中存在空指针Cor

3、rectness37ANP: Null pointer dereference in method on exception path方法中存在某异常路径中的空指针Correctness38ANP: Possible null pointer dereference in method方法中存在可能在运行时出现的空指针异常Correctness39ANP: Possible null pointer dereference in method on exception path方法中存在可能在某些异常路径下出现的空指针异常Correctness41CNm: Class defines equa

4、l(); should it be equals()?类中定义了equal方法，但是没有重写java.lang.Object中equal方法，这也有可能是有意这么做的Correctness42BNm: Confusing method names一些方法名只有大小写的区别，容易混绕Correctness43BNm: Confusing method name方法名和其超类的类名相同Correctness44CNm: Class defines hashcode(); should it be hashCode()?类中定义了hashCode()方法，但是没有重写中的hashCode()方法，这

5、也有可能是有意这么做的Correctness45CNm: Class defines tostring(); should it be toString()?类中定义了tostring()方法，但是没有重写中的tostring()方法，这也有可能是有意这么做的Correctness46ANm: Very confusing method names一些方法名只有大小写的区别，特别容易混绕Correctness47AODR: Method may fail to close database resource方法可能没有关闭数据源Correctness48AODR: Method may fai

6、l to close database resource on exception方法在异常时可能无法关闭数据源Correctness49AOS: Method may fail to close stream方法可能没有关闭流Correctness50AOS: Method may fail to close stream on exception方法在异常时可能无法关闭流Correctness53CRCN: Redundant comparision to null of previously checked value预测值的几个比较的值中有null值Correctness54CRCN:

7、 Redundant comparison to null几个比较的值中有null值Correctness57CRV: Method ignores return value方法忽略了返回值Correctness59ASI: Static initializer for class creates instance before all static final fields assigned类的静态初始化器实例化一个该类对象要在所有的常量属性定义之前Correctness72CUwF: Unwritten field永远不会写到的字段，所有读取将返回默认值Correctness83AMS:

8、Field isn't final but should be字段应该为常量的却不是常量Malicious code vulnerability86AIS2: Inconsistent synchronization类中字段访问不同步Multithreaded correctness88AML: Method synchronizes on an updated field方法从一个可变字段对象的引用中同步。这是不太可能有用的，因为不同的线程可以在不同的对象上同步。Multithreaded correctness92CRu: Invokes run on a thread (did

9、you mean to start it instead?)当一个类继承Runnable接口时候，还去调用run方法，实际上只需要调用Start方法就可以启动新的线程，Multithreaded correctness93CSC: Constructor invokes Thread.start()构造函数调用Thread.start（）Multithreaded correctness102CDm: Method invokes dubious new String(String) constructor; just use the argument方法中调用String的构造函数来新建一个

10、字符串，直接使用其参数即可Performance103ADm: Method invokes dubious String.equals(""); use String.length() = 0 instead方法中调用了不确定的String.equals("")，使用String.length() = 0来代替Performance104ADm: Method invokes toString() method on a String; just use the String方法中用一个字符串去调用方法toString（），用String就可以了Per

11、formance105CDm: Method invokes dubious new String() constructor; just use ""方法中新建一个空字符串用new String（）。直接用“”就可以了Performance106CFI: Empty finalizer should be deleted空finalizer（）方法是没有用的，所以应该予以删除Performance114CUPM: Private method is never called这个私有方法从来没有被调用到Performance115CUrF: Unread field读不到的

12、字段，应该从类中删除Performance116CUuF: Unused field读不到的字段，应该从类中删除PerformanceDescriptionsAM: Creates an empty jar file entryThe 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

13、the calls to putNextEntry() and closeEntry().AM: Creates an empty zip file entryThe 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 cl

14、oseEntry().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

15、(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 typ

16、o.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

17、 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

18、 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

19、()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

20、 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 compareTo().  To correctly override the

21、compareTo() method in the Comparable interface, the parameter of compareTo() must have type .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

22、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 a

23、ppropriate. 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, t

24、his call should always return false.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 a

25、s 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

26、 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 objects for reference equality using the = or != o

27、perators. Unless both strings are either constants in a source file, or have been interned using the Sern() method, the same string value may be represented by two different String objects. Consider using the equals(Object) method instead.Eq: Covariant equals() method definedThis class defi

28、nes a covariant version of equals().  To correctly override the equals() method in , the parameter of equals() must have type .Eq: Covariant equals() method defined, Object.equals(Object) inheritedThis class defines a covariant version of the equals() method, but calls the normal equals(Object)

29、 method defined in the base class.  The class should probably define a non-covariant version of equals().  (I.e., a method with the signature boolean equals(java.lang.Object).FI: Explicit invocation of finalizerThis method contains an explicit invocation of the finalize() method on an obje

30、ct.  Because finalizer methods are supposed to be executed once, and only by the VM, this is a bad idea.FI: Finalizer does not call superclass finalizerThis finalize() method does not make a call to its superclass's finalize() method.  So, any finalizer actions defined for the supercla

31、ss will not be performed.  Add a call to super.finalize().FI: Finalizer nullifies superclass finalizerThis 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

32、 this is intended, delete this method.HE: Class 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.HE: Class defines equals() and uses Object.hashC

33、ode()This class overrides equals(Object), but does not override hashCode(), and inherits the implementation of hashCode() from (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 ob

34、jects 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.HE: Class defines hashCode() but not equals()This class defines a hash

35、Code() method but not an equals() method.  Therefore, the class may violate the invariant that equal objects must have equal hashcodes.HE: Class defines hashCode() and uses Object.equals()This class defines a hashCode() method but inherits its equals() method from (which defines equality by com

36、paring 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 comp

37、licated than simple reference equality.)HE: Class inherits equals() and uses Object.hashCode()This class inherits equals(Object) from an abstract superclass, and hashCode() from from (which returns the identity hash code, an arbitrary value assigned to the object by the VM).  Therefore, the cla

38、ss 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.IC: Initializa

39、tion 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 t

40、he 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

41、next() method can't throw NoSuchElement exceptionThis class implements the interface.  However, its next() method is not capable of throwing .  The next() method should be changed so it throws NoSuchElementException if is called when there are no more elements to return.MF: Class defin

42、es 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 fiel

43、dThis 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 o

44、bviously holding a lock on the object.  Calling notify() or notifyAll() without a lock held will result in an IllegalMonitorStateException being thrown.MWN: Mismatched wait()This method calls Object.wait() without obviously holding a lock on the object.  Calling wait() without a lock held

45、will result in an IllegalMonitorStateException being thrown.NP: Null pointer dereference in methodA null pointer is dereferenced here.  This will lead to a NullPointerException when the code is executed.NP: Null pointer dereference in method on exception pathA pointer which is null on an except

46、ion 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

47、 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 NullPointerException when the code is executed.NP: Possible null pointer dereference in method on exceptio

48、n pathA 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 FindBug

49、s 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-ci

50、rcuit 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 equ

51、al(); should it be equals()?This class defines a method equal(Object).  This method does not override the equals(Object) method in , which is probably what was intended.Nm: Confusing method namesThe referenced methods have names that differ only by capitalization.Nm: Confusing method nameThis m

52、ethod 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 hashcode().  This method does not override the hashCode() method in , which is probably what was intended.Nm: Class defines tostring()

53、; should it be toString()?This class defines a method called tostring().  This method does not override the toString() method in , which is probably what was intended.Nm: Very confusing method namesThe referenced methods have names that differ only by capitalization.ODR: Method may fail to clos

54、e 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 pat

55、hs 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 an

56、y 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 wi

57、th 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 ge

58、nerally a good idea to use a finally block to ensure that streams are closed.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 pat

59、hs 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.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