FindBugs Tools FAQ

1,am:creates an empty Jar file entry (am_creates_empty_jar_file_entry)/am:creates a empty zip file entry (am_creates_em Pty_zip_file_entry)

Example code:

ZipEntry entry = new ZipEntry (PATH);

Zos.putnextentry (entry);

Zos.closeentry ();

Reason:

The Closeentry () function is called immediately after calling Putnextentry () in the code, causing the contents of the jar file to be empty because the contents of the jar package are written between Putnextentry () and closeentry () two function calls. (Sometimes you might intentionally build an empty directory, so it's not necessarily a bug)

2,bc:equals method should not assume anything on the type of its argument (bc_equals_method_should_work_for_all_object S

Example code:

public class Foo {

Some code

public void equals (Object o) {

Foo other = (foo) o;

The real equals code

}

}

Reason:

When you implement the Equals method of a class, you should not have any pre-set parameters. As the above code is written, the parameter o is definitely an object of the Foo class. But if the argument O is not a Foo class or its subclass when the function is called, it will cause the code to throw a classcastexception. So in implementing the Equals method, you should add a judgment that returns false if the parameter o is not an Foo class object.

3,bc:random object created and used only once (dmi_random_used_only_once)

Example code:

public int getrandom (int seed) {

return new Random (seed). Nextint ();

}

Reason:

Since Java.util.Random is a pseudo-random function, the returned random number is the same if the incoming seed value is the same. Therefore, it is not necessary to new random numbers to be calculated each time. If you want to really get an unpredictable random number, it is recommended to use Java.security.SecureRandom, which inherits from Random and is a strong random number generator. So the above code can be modified to:

public class Test extends thread{

Private SecureRandom ran;

Test (int seed) {

ran = new SecureRandom ();

}

public int getrandom (int seed) {

return Ran.nextint ();

}

}

4,cn:class implements Cloneable but does not define or use Clone method (CN_IDIOM)

Example code:

public class Foo implements cloneable {

Public Object Clone () throws Clonenotsupportedexception {

return Super.clone ();

}

}

Reason:

The class definition implements the Cloneable interface, but does not define or use the Clone method, which is missing the red font portion.

5,cn:clone method does not call Super.clone () (Cn_idiom_no_super_call)

Example code:

public class Foo implements cloneable {

Public Object Clone () throws Clonenotsupportedexception {

return Super.clone ();

}

}

Reason:

The Clone method does not call the Super.clone () method, and if it is not called, it causes the object parent-child hierarchy to not be established correctly, resulting in the inability to assemble the object correctly.

6,cn:class defines clone () but doesn ' t implement cloneable (Cn_implements_clone_but_not_cloneable)

Example code:

public class foo{

Public Object Clone () throws Clonenotsupportedexception {

return Super.clone ();

}

}

Reason:

The meaning of this usage is that you can standardize the implementation of the clone of the subclass of the class, if you do want to do this, it's not a bug, otherwise it's a bug.

7,de:method might drop exception (De_might_drop)/de:method might ignore exception (De_might_ignore)

Example code:

Try{}catch (Exception ex) {}

Reason:

The method may throw an exception or ignore the exception, and the exception needs to be handled, that is, the exception needs to be handled in the catch body.

8,dmi:don ' t use RemoveAll to clear a collection (dmi_using_removeall_to_clear_collection)

Reason:

It is recommended that you do not use the Collection.removeall (collection) method to delete all elements in collection, and use Collection.clear (). By comparing the code implementations of the two, you can see:

RemoveAll () Source code:

public boolean RemoveAll (collection<?> c) {

Boolean modified = false;

Iterator<?> e = Iterator ();

while (E.hasnext ()) {

if (C.contains (E.next ())) {

E.remove ();

Modified = true;

}

}

return modified;

}

Clear () Source code:

public void Clear () {

iterator<e> E = Iterator ();

while (E.hasnext ()) {

E.next ();

E.remove ();

}

}

The former is the collection in the comparison parameter and whether there is an intersection in the collection to remove the element, and then the intersection element is removed, and the latter is deleted directly from the collenction element. Obviously the latter is more efficient than the former, and for some special collenction it is easy to throw some anomalies, such as concurrentmodificationexception

9,es:comparison of String parameter using = = or! = (ES_COMPARING_PARAMETER_STRING_WITH_EQ)

Cause: When comparing the contents of two strings, it is better to use the object comparison method equal only if the two strings are constants in the source file or are compared using intern (). Attached string comparison:

String str1 = "Java";

String str2 = "Java";

System.out.print (STR1==STR2);

Result: True (both are constants)

String str1 = new String ("Java");

String str2 = new String ("Java");

System.out.print (STR1==STR2);

Result: False (both objects)

String str1 = "Java";

String str2 = "blog";

String s = str1+str2;

System.out.print (s== "Javablog");

Result: false (s not constant, object)

String S1 = "Java";

String s2 = new String ("Java");

System.out.print (S1.intern () ==s2.intern ());

Result: True (but the Intern () method is not uniform in efficiency and implementation)

FindBugs Tools FAQ