If there is reprint, please indicate the source: http://blog.csdn.net/yihui823/article/details/6866801
It is not a literal translation. It adds your own understanding. If you have any questions, please let us know.
Based on version: findbugs version 1.3.9.
AM: creates an empty jar file entry (am_creates_empty_jar_file_entry)
No other operations are performed on the JAR file between putnextentry () and closeentry. This will generate an empty entry for the JAR file.
The Code CILS putnextentry (), immediately followed by a call to closeentry (). this results in an empty jarfile entry. the contents of the entry shocould be written to the jarfile between the callto putnextentry () and closeentry ().
AM: creates an empty ZIP file entry (am_creates_empty_zip_file_entry)
No other operations are performed on the zip file between putnextentry () and closeentry. This will generate an empty entry for the ZIP file.
The Code CILS putnextentry (), immediately followed by a call to closeentry (). this results in an empty zipfile entry. the contents of the entry shocould be written to the zipfile between the callto putnextentry () and closeentry ().
BC: equals method shocould not assume anything about the type of its argument (bc_equals_method_should_work_for_all_objects)
In the equals method, parameter type matching is not judged. The modification method is very simple, plus:
If (! (O instanceof [current class]) {
Return false;
}
The equals (Object O) method shouldn't make any assumptions about the type of O. It shoshould simply return false if O is not the same type as this.
BC: random object created and used only once (dmi_random_used_only_once)
A java. util. Random object is used only once, and a random number is generated and discarded. Normally, you should save the object and call this object wherever a random number is needed.
This Code creates a java. util. random object, uses it to generate one random number, and then discards the random object. this produces mediocrequality 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.
Bit: Check for sign of bitwise operation (bit_signed_check)
In a judgment statement, the bitwise operation is used and the comparison is greater than 0. For example:
(Event. Detail & SWT. Selected)> 0)
The intention of this judgment is that there are non-0 digits after the two numbers are done and operated. However, if you are not careful, the operation result is a negative number, which is a bug. It is best to use "! = "Replace"> 0"
This method compares an expression such
(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 bokoski
CN: class implements cloneable but does not define or use clone method (cn_idiom)
A class implements the cloneable interface, but does not declare or use the clone method. Because the clone method is a method of the object class, the current class does not declare this method and does not compile and fail. However, the clone operation requires copying fields one by one, so it is not correct to declare the clone method.
Class implements cloneable but does not define or use the clone method.
CN: clone method does not call Super. Clone () (cn_idiom_no_super_call)
A non-final class defines the clone () method, but does not call Super. Clone () in the method ().
It seems that super. Clone () should not be called (). If a is the parent class of B, then B calls super. Clone (), then the clone method of B returns the instance of a, which looks wrong.
However, if all clone () Methods call Super. Clone (), the object. Clone () method is called, and the correct type is returned.
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 callsuper. 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.
CN: class defines clone () but doesn't implement cloneable (cn_implements_clone_but_not_cloneable)
Class defines the clone () method, but does not declare the implementation of the cloneable interface. This is not a big problem. Just check whether the statement is missing.
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.
CO: abstract class defines covariant compareto () method (co_policact_self)
Class defines a compareto () method. Its parameter is not of the object type. To correctly implement the compareto () method of the comparable interface, the best practice is that the parameter of the compareto () method is the object class.
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.
CO: covariant compareto () method defined (co_self_no_object)
Same as above
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.
DE: method might drop exception (de_might_drop)
This method may give up the exception. Normally, exceptions should be handled, reported in some way, or thrown to the outer layer.
This method might drop an exception. In general, exceptions shoshould be handled or reported in some way, or they shoshould be thrown out of the method.
DE: method might ignore exception (de_might_ignore)
This method may ignore exceptions. Normally, exceptions should be handled, reported in some way, or thrown to the outer layer.
This method might ignore an exception. In general, exceptions shoshould be handled or reported in some way, or they shocould be thrown out of the method.
DMI: Don't use removeall to clear a collection (dmi_using_removeall_to_clear_collection)
If you want to delete all elements in the Set, use the clear method of the Set instead of the C. removeall (c) method. Call C. removeall (c) to clear the set, which is not clean and prone to errors. A concurrentmodificationexception may be thrown.
If you want to remove all elements from a collection C, use C. clear, not C. removeall (c ). calling C. removeall (c) to clear a collection is less clear, susceptible to errors from typos, less efficient and for some collections, might throw a concurrentmodificationexception.
DP: classloaders shoshould only be created inside doprivileged block (dp_create_classloader_inside_do_privileged)
This code writes a classloader that requires the security manager. If the code needs to be authorized as a security permission but may be called by Insecure code, the classloader should be placed in the 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.
DP: method invoked that shocould be only be invoked inside a doprivileged block (dp_do_inside_do_privileged)
The Code calls a method that requires security permission check. If the code needs to be authorized as a security permission but may be called by Insecure code, the classloader should be placed in the 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.
DM: Method invokes system. Exit (...) (dm_exit)
System. Exit is called to shut down virtual machine processes. This can only be used when appropriate. This call will make your code difficult or even impossible to be called by other code. It is better to throw a runtimeexception instead.
Invoking system. exit shuts down the entire Java virtual machine. this shoshould only been done when it is appropriate. such callmake it hard or impossible for your code to be invoked by other code. consider throwing a runtimeexception instead.
DM: Method invokes Dangerous Method runfinalizersonexit (dm_run_finalizers_on_exit)
Never call system. runfinalizersonexit or runtime. runfinalizersonexit for any reason. They are very dangerous methods in the Java package.
-- Java Godfather Joshua Bloch
Never call system. runfinalizersonexit or runtime. runfinalizersonexit for any reason: they are among the most dangerous methods in the Java libraries. -- Joshua Bloch
ES: Comparison of string parameter using = or! = (Es_comparing_parameter_string_with_eq)
Use = or! = To compare strings. This method is used to compare strings. Instead of comparing strings with the same content, it is used to compare whether a string is the same object. Use the equals method to replace this comparison.
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.
ES: Comparison of string objects using = or! = (Es_comparing_strings_with_eq)
Same as above
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.
EQ: abstract class defines covariant equals () method (eq_policact_self)
This class defines the equals () method, but the parameter is a subclass of the object. Correctly override the equals () method. The parameter must be an 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.
EQ: equals checks for noncompatible operand (eq_check_for_operand_not_compatible_with_this)
In the equals method, when checking the parameter type, it checks other types except itself. For example:
Public Boolean equals (Object O ){
If (O instanceof Foo)
Return name. Equals (FOO) O). Name );
Else if (O instanceof string)
Return name. Equals (O );
Else return false;
This writing method is a bad habit, and it makes the code hard to understand and migrate.
This equals method is checking to see if the argument is some incompatible Type (I. E ., A class that is neither a supertype nor subtype of the class that defines the equals method ). for example, the foo class might have an equals method that looks like:
Public Boolean equals (Object O ){
If (O instanceof Foo)
Return name. Equals (FOO) O). Name );
Else if (O instanceof string)
Return name. Equals (O );
Else return false;
This is considered bad practice, as it makes it very hard to implement an equals method that is using Ric and transitive. Without those properties, very unexpected behavoirs are possible.
EQ: class defines compareto (...) and uses Object. Equals () (eq_compareto_use_object_equals)
This class defines compareto (...) But directly inherits the equals () method of the object. Generally, the compareto method returns 0 only when the equals method returns true. If this principle is not followed, some strange and unpredictable problems may occur. In Java 5, the priorityqueue. Remove method uses the compareto method, but in Java 6, it uses the equals method.
Needless to say.
This class defines a compareto (...) method but inherits its equals () method from Java. lang. object. generally, the value of compareto shoshould 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 stronugly 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 shoshould clearly indicate this fact. the recommended language is
"NOTE: This class has a natural ordering that is inconsistent with equals ."
EQ: equals method fails for subtypes (eq_getclass_and_class_constant)
This class writes its own equals method, but this method is not inherited when comparing the object type of the parameter. If a subclass inherits this class, an error will occur. For example, the foo class check is:
If (FOO. Class = O. getclass ()). It is best to change it:
If (this. getclass () = O. getclass ())
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 ().
EQ: covariant equals () method defined (eq_self_no_object)
The parameter of the equals () method, preferably the object. If not, problems may occur.
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.