Findbugs缺陷等级对照表

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

2、als() comparing differentCorrectnesstypes调用Equal方法去比较不同的数据类型17AES: Comparison of String objects using =Correctnessor !=使用=或者！=去比较字符申或对象29BIJU: TestCase implements setUp but doesn'tCorrectnesscall super.setUp()测试实例实现了 setUp ()但没有调用super.setUp()36ANP: Null pointer dereference in methodCorrectness方

3、法中存在空指针37ANP: Null pointer dereference in method onCorrectnessexception path方法中存在某异常路径中的空指针38ANP: Possible null pointer dereference inCorrectnessmethod方法中存在可能在运行时出现的空指针异常3941CorrectnessCorrectnessNP: Possible null pointer dereference in method on exception path方法中存在可能在某些异常路径下出现的空指针异 常Nm: Class defin

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

5、也有可能是 有意这么做的Nm: Class defines tostring(); should it betoString()?CorrectnessCorrectness45类中定义了 tostring()方法，但是没有重写java.lang.Object 中的tostring() 方法，这也有可能是有意这么做的Correctness46Nm: Very confusing method names一些方法名只有大小写的区别，特别容易混绕Correctness47ODR: Method may fail to close database resource方法可能没有关闭数据源Correc

6、tness48ODR: Method may fail to close database resource on exceptionCorrectness49方法在异常时可能无法关闭数据源OS: Method may fail to close stream方法可能没有关闭流Correctness50OS: Method may fail to close stream on exceptionCorrectness53方法在异常时可能无法关闭流RCN: Redundant comparision to null of previously checked value预测值的几个比较的值中有

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

8、将返回默认值Correctness83MS: Field isn't final but should be字段应该为常量的却不是常量Malicious code vulnerability86IS2: Inconsistent synchronization类中字段访问不同步Multithreaded correctness88ML: Method synchronizes on an updated field方法从一个可变字段对象的引用中同步。这是不太能有用的，因为不同的线程可以在不同的对象上 同步。Multithreaded correctness92Ru: Invokes r

9、un on a thread (did you mean to start it instead?) AlZ当一个类继承Runnable接口时候，还去调用run方 法，实际上只需要调用Start方法就可以启动新的 线程，Multithreaded correctness93 CSC: Constructor invokes Thread.start() 构造函数调用Thread.start102103()Dm: Method invokes dubious newString(String) constructor; just use the argument方法中调用String的构造函数来

10、新建一个字符 申，直接使用其参数即可Dm: Method invokes dubiousString.equals(""); use String.length() = 0 insteadMultithreaded correctnessPerformancePerformance方法中调用了不确定的String.equals(""),使用String.length() = 0 来代替Dm: Method invokes toString() method on a104PerformanceString; just use the String方法中用

11、一个字符申去调用方法toString (),用105PerformanceString就可以了106CFI: Empty finalizer should be deletedPerformance空finalizer()方法是没有用的，所以应该予以删除114CUPM: Private method is never calledPerformance这个私有方法从来没有被调用到115CUrF: Unread field读不到的字段，应该从类中删除Performance116CUuF: Unused fieldPerformanceDm: Method invokes dubious new

12、String() constructor; just use ""方法中新建一个空字符申用new String ()。直接 用就可以了读不到的字段，应该从类中删除DescriptionsAM: Creates an empty jar file entryThe code calls putNextEntry() , immediately followed by a call to cioseEntry() . This results in an empty JarFile entry. The contents of the entry should be writt

13、en to the JarFile between 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 c

14、alls to putNextEntry() and closeEntry().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 compar

15、es 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

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

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

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

19、hod 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 thatBsclone() method will return an object of typeA w

20、hich violates thestandard 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 ofcompareTo() . To correctlyover

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

22、Method might ignore exceptionThis method might ignore an exception.In general, exceptions shouldbe 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

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

24、() method, this 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 alw

25、ays 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 typ

26、es.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 java.lang.String objects for reference

27、 equality using the = or != operators. Unless both strings are either constants in a source file, or have been interned using theSern() method, thesame string value may be represented by two different String objects.Consider using the equals(Object) method instead.Eq: Covariant equals() met

28、hod definedThis class defines a covariant version ofequals() . To correctlyoverride theequals。 method in java.lang.Object , the parameter of equals。must have type java.lang.ObjectEq: Covariant equals() method defined, Object.equals(Object)inheritedThis class defines a covariant version of theequals。

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

30、 invocation of thefinalize。method onan object. 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'sfinalize()method. So, any finalizer act

31、ions defined for the superclass will not be performed. Add a call to super.finalize() .FI: Finalizer nullifies superclass finalizerThis empty finalize。method explicitly negates the effect of anyfinalizer defined by its superclass.Any finalizer actions definedfor the superclass will not be performed.

32、Unless 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.hash

33、Code()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

34、 that equal objects must have equal hashcodes.hashCode()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 method to throw UnsupportedOperationExceptionHE: Class defines hashCode() but not equals()This class de

35、fines a hashCode()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 java.lang.Object (which de

36、fines 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

37、more complicated than simple reference equality.)HE: Class inherits equals() and uses Object.hashCode()This class inheritsequals(Object) from an abstract superclass, andhashCode() from from java.lang.Object (which returns the identity hash code, an arbitrary value assigned to the object by theVM). T

38、herefore, 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 thehashCode()method to throw UnsupportedOperationException

39、IC: Initialization circularityA circularity was detected in the static initializers of the two classes referenced by the bug instance.Many kinds of unexpectedbehavior may arise from such circularity.IJU: TestCase implements setUp but doesn't call super.setUp()Class is a JUnit TestCase and implem

40、ents 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: Ite

41、rator next() method can't throw NoSuchElement exceptionThis 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

42、are no more elements to return.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:

43、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 O

44、bject.notify() or Object.notifyAll() without obviously holding a lock on the object.Calling notify() ornotifyAll() 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. Cal

45、ling wait() without a lock held will result in an IllegalMonitorStateException being thrown.NP: Null pointer dereference in methodA null pointer is dereferenced here.This will lead to aNullPointerException when the code is executed.NP: Null pointer dereference in method on exception pathA pointer wh

46、ich 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 pruneinfeasible exception paths, this may be a false warning.Also note that FindBugs considers the default case of a switch stateme

47、nt 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.Thismay lead to a NullPointerException when the code is executed.NP: Possible null pointer dereference in method on excep

48、tion 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 FindBugs conside

49、rs 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 log

50、ic 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(); sho

51、uld 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.Nm: Confusing method namesThe referenced methods have names that differ only by capitalization.Nm: Confusing method nameThis

52、 method has the same name as the superclass of the class it isdefined 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 java.lang.Object , which is probably what was intended.Nm: Class defin

53、es 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.Nm: Very confusing method namesThe referenced methods have names that differ only by capitalization.ODR

54、: 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 r

55、esources 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 n

56、ot 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 databaseresources on all paths out of a method may result in poor performance, and could cause the application to have problems commun

57、icating 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 afile descriptor leak.It is generally a good idea to use afinallyblock 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, pas