Findbugs缺陷等级对照表

FindBugs Bug Descriptions

This document lists the standard bug patterns reported by version

0.8.5.

Summary

序等号 级

14 A

Description Category

Correctness

Correctness

EC: Call to equals() with null argument

调用Equal方法的参数为空

EC: Call to equals() comparing different

15 A interface types

调用Equal方法去比较不同的接口类型

EC: Call to equals() comparing different

16 A types

调用Equal方法去比较不同的数据类型

ES: Comparison of String objects using ==

17 A

or !=

使用== 或者 != 去比较字符串或对象

IJU: TestCase implements setUp but doesn't

call ()

29 B

测试实例实现了setUp（）但没有调用（）

36 A

NP: Null pointer dereference in method

方法中存在空指针

Correctness

Correctness

Correctness

Correctness

Correctness

NP: Null pointer dereference in method on

37 A exception path

方法中存在某异常路径中的空指针

NP: Possible null pointer dereference in

38 A method

方法中存在可能在运行时出现的空指针异常

Correctness

NP: Possible null pointer dereference in

method on exception path

39 A Correctness

方法中存在可能在某些异常路径下出现的空指针异常

Nm: Class defines equal(); should it be

equals()?

41 C 类中定义了equal方法，但是没有重写Correctness

中equal方法，这也有可能是有意这么做的

42 B

43 B

Nm: Confusing method names

一些方法名只有大小写的区别，容易混绕

Nm: Confusing method name

方法名和其超类的类名相同

Correctness

Correctness

Nm: Class defines hashcode(); should it be

hashCode()?

44 C 类中定义了hashCode()方法，但是没有重写中的hashCode()方法，这也有可能是有意这么做的

Nm: Class defines tostring(); should it be

toString()?

45 C 类中定义了tostring()方法，但是没有重写中的tostring()方法，这也有可能是有意这么做的

46 A

Nm: Very confusing method names

一些方法名只有大小写的区别，特别容易混绕

Correctness

Correctness

Correctness

Correctness

ODR: Method may fail to close database

47 A resource

方法可能没有关闭数据源

ODR: Method may fail to close database

48 A resource on exception

方法在异常时可能无法关闭数据源

49 A

OS: Method may fail to close stream

方法可能没有关闭流

Correctness

Correctness

Correctness

OS: Method may fail to close stream on

50 A exception

方法在异常时可能无法关闭流

RCN: Redundant comparision to null of

53 C previously checked value

预测值的几个比较的值中有null值

54 C

57 C

RCN: Redundant comparison to null

几个比较的值中有null值

RV: Method ignores return value

方法忽略了返回值

Correctness

Correctness

Correctness

SI: Static initializer for class creates

instance before all static final fields

59 A assigned Correctness

类的静态初始化器实例化一个该类对象要在所有的常量属性定义之前

72 C

UwF: Unwritten field

永远不会写到的字段，所有读取将返回默认值

Correctness

83 A

86 A

MS: Field isn't final but should be

字段应该为常量的却不是常量

IS2: Inconsistent synchronization

类中字段访问不同步

Malicious code

vulnerability

Multithreaded

correctness

ML: Method synchronizes on an updated field

方法从一个可变字段对象的引用中同步。这是不太Multithreaded

88 A

可能有用的，因为不同的线程可以在不同的对象上correctness

同步。

Ru: Invokes run on a thread (did you mean to

start it instead?)

Multithreaded

92 C 当一个类继承Runnable接口时候，还去调用run方correctness

法，实际上只需要调用Start方法就可以启动新的线程，

93 C

SC: Constructor invokes ()

构造函数调用（）

Multithreaded

correctness

Dm: Method invokes dubious new

String(String) constructor; just use the

102 C argument

方法中调用String的构造函数来新建一个字符串，直接使用其参数即可

Performance

Dm: Method invokes dubious

(""); use () == 0

103 A instead Performance

方法中调用了不确定的("")，使用() == 0来代替

Dm: Method invokes toString() method on a

String; just use the String

104 A Performance

方法中用一个字符串去调用方法toString（），用String就可以了

Dm: Method invokes dubious new String()

constructor; just use ""

105 C Performance

方法中新建一个空字符串用new String（）。直接用“”就可以了

FI: Empty finalizer should be deleted

106 C

空finalizer（）方法是没有用的，所以应该予Performance

以删除

114 C

115 C

UPM: Private method is never called

这个私有方法从来没有被调用到

UrF: Unread field

读不到的字段，应该从类中删除

Performance

Performance

Performance 116 C UuF: Unused field

读不到的字段，应该从类中删除

Descriptions

AM: Creates an empty jar file entry

The 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 the calls to

putNextEntry() and

closeEntry().

AM: Creates an empty zip file entry

The 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

closeEntry().

BIT: Incompatible bit masks

This 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 masks

This 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 masks

This 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 wrongly

This method overrides a method found in a parent class, where that

class is an Adapter that implements a listener defined in the

or 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

0

A 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 method

Class implements Cloneable but does not define or use the clone method.

CN: clone method does not call ()

This class defines a clone() method that does not call (),

and is not final. If this class ("A") is extended by a subclass ("B"),

and the subclass

B calls (), 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 (), then they are guaranteed to

use (), which always returns an object of the correct type.

Co: Covariant compareTo() method defined

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

.

DE: Method might drop exception

This 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 exception

This 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 (...)

Invoking 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 argument

This method calls equals(Object), passing a null value as the argument.

According to the contract of the equals() method, this call should

always return

false.

EC: Call to equals() comparing different interface types

This 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 types

This 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

objects for reference equality using

the == or != operators. Unless both strings are either constants in a

source file, or have been interned using the

() method, the

same string value may be represented by two different String objects.

Consider using the

equals(Object) method instead.

Eq: Covariant equals() method defined

This class defines 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)

inherited

This class defines a covariant version of the

equals() method, but calls

the normal

equals(Object) 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().

FI: Explicit invocation of finalizer

This method contains an explicit invocation of the

finalize() method on

an 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 finalizer

This

finalize() method does not make a call to its superclass's

finalize()

method. So, any finalizer actions defined for the superclass will not

be performed. Add a call to

ze().

FI: Finalizer nullifies superclass finalizer

This 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 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 de()

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 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.

HE: Class defines hashCode() but not equals()

This class defines 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 ()

This class defines a

hashCode() method but inherits its

equals() method

from

(which defines 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 more

complicated than simple reference equality.)

HE: Class inherits equals() and uses de()

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 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 the

hashCode()

method to throw

UnsupportedOperationException.

IC: Initialization circularity

A 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 ()

Class is a JUnit TestCase and implements the setUp method. The setUp

method should call (), but doesn't.

IMSE: Dubious catching of IllegalMonitorStateException

IllegalMonitorStateException 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 exception

This class implements the

or interface. However, its

next() method is not capable of throwing

ElementException. The

next() method should be changed so it

throws

NoSuchElementException if is called when there are no more elements

to return.

MF: Class defines field that obscures a superclass field

This 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 field

This 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 () or All() without

obviously 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 () without obviously holding a lock on the

object. Calling wait() without a lock held will result in an

IllegalMonitorStateException being thrown.

NP: Null pointer dereference in method

A null pointer is dereferenced here. This will lead to a

NullPointerException when the code is executed.

NP: Null pointer dereference in method on exception path

A pointer which 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 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 exception path, since the default case is often

infeasible.

NP: Possible null pointer dereference in method

A 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 exception

path

A 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 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 logic

This 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

equal(Object). This method does not

override the

equals(Object) method in

, which is probably

what was intended.

Nm: Confusing method names

The referenced methods have names that differ only by capitalization.

Nm: Confusing method name

This 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

hashcode(). This method does not

override the

hashCode() method in

, which is probably what

was intended.

Nm: Class defines tostring(); 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 names

The referenced methods have names that differ only by capitalization.

ODR: Method may fail to close database resource

The 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 exception

The 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 stream

The 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

finally

block to ensure that streams are closed.

OS: Method may fail to close stream on exception

The 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

finally block to ensure that streams are closed.

PZLA: Consider returning a zero length array rather than null

It 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,

les()

returns an empty list if given a directory containing no files, and

returns null if the file is not a directory.

RC: Suspicious reference comparison

This 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 r, ,

etc.

RCN: Redundant comparision to null of previously checked value

This method contains a redundant comparison of a reference value to

null. Two types of redundant comparison are reported:

Both values compared are definitely null



One value is definitely null and the other is definitely not null



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 null

This method contains a redundant comparison of a reference value to

null. Two types of redundant comparison are reported:

Both values compared are definitely null



One value is definitely null and the other is definitely not null



This particular warning represents two specific kinds of redundant

comparisions:

1. A value was dereferenced, and later explicitly compared to null:

this often indicates an error in the method

2. A literal null value was explicitly compared to null: this may

indicate that the method was modified without complete

understanding of the invariants of the method

RR: Method ignores results of ()

This method ignores the return value of one of the variants of

() which can return multiple bytes. If the return

value is not checked, the caller will not be able to correctly handle

the case where fewer bytes were read than the caller requested. This

is a particularly insidious kind of bug, because in many programs,

reads from input streams usually do read the full amount of data

requested, causing the program to fail only sporadically.

RR: Method ignores results of ()

This method ignores the return value of

() which

can skip multiple bytes. If the return value is not checked, the

caller will not be able to correctly handle the case where fewer bytes

were skipped than the caller requested. This is a particularly

insidious kind of bug, because in many programs, skips from input

streams usually do skip the full amount of data requested, causing the

program to fail only sporadically. With Buffered streams, however,

skip() will only skip data in the buffer, and will routinely fail to

skip the requested number of bytes.

RV: Method ignores return value

The return value of this method should be checked.

SA: Self assignment of field

This 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 assigned

The 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 operator

Type 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 class

This Serializable class defines a non-primitive instance field which is

neither transient, Serializable, or

, and does not appear

to implement the

Externalizable interface or the

readObject() and

writeObject() methods. Objects of this class will not be deserialized

correctly if a non-Serializable object is stored in this field.

Se: serialVersionUID isn't final

This class defines a

serialVersionUID field that is not final. The

field should be made final if it is intended to specify the version UID

for purposes of serialization.

Se: serialVersionUID isn't long

This class defines a

serialVersionUID field that is not long. The field

should be made long if it is intended to specify the version UID for

purposes of serialization.

Se: serialVersionUID isn't static

This class defines a

serialVersionUID field that is not static. The

field should be made static if it is intended to specify the version

UID for purposes of serialization.

Se: Class is Serializable but its superclass doesn't define a

void constructor

This class implements the

Serializable interface and its superclass does

not. When such an object is deserialized, the fields of the superclass

need to be initialized by invoking the void constructor of the

superclass. Since the superclass does not have one, serialization and

deserialization will fail at runtime.

Se: Class is Externalizable but doesn't define a void

constructor

This class implements the

Externalizable interface, but does not define a

void constructor. When Externalizable objects are deserialized, they

first need to be constructed by invoking the void constructor. Since

this class does not have one, serialization and deserialization will

fail at runtime.

SnVI: Class is Serializable, but doesn't define

serialVersionUID

This class implements the

Serializable interface, but does not define a

serialVersionUID field. A change as simple as adding a reference to

a .class object will add synthetic fields to the class, which will

unfortunately change the implicit serialVersionUID (e.g., adding a

reference to

will generate a static field

class$java$lang$String). Also, different source code to bytecode compilers

may use different naming conventions for synthetic variables generated

for references to class objects or inner classes. To ensure

interoperability of Serializable across versions, consider adding an

explicit serialVersionUID.

UCF: Useless control flow in method

This method contains a useless control flow statement. Often, this is

caused by inadvertently using an empty statement as the body of an

if

statement, e.g.:

if ( == 1);

n("Hello, " + argv[0]);

UI: Usage of GetResource may be unsafe if class is extended

Calling

ss().getResource(...) could give results other than

expected if this class is extended by a class in another package.

UR: Uninitialized read of field in constructor

This 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 field

This 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 object

Returning 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 public

A class's

finalize() method should have protected access, not public.

MS: Method may expose internal static state by storing a

mutable object into a static field

This 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

code

A 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 array

A 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 protected

A 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 array

A 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 Hashtable

A 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

protected

A 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 protected

A 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 be

A 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 held

Waiting 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 field

This 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

/~pugh/java/memoryModel/.

IS2: Inconsistent synchronization

The fields of this class appear to be accessed inconsistently with

respect to synchronization. This bug report indicates that the bug

pattern detector judged that

1. The class contains a mix of locked and unlocked accesses,

2. At least one locked access was performed by one of the class's

own methods, and

3. The number of unsynchronized field accesses (reads and writes)

was no more than one third of all accesses, with writes being

weighed twice as high as reads

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 field

This 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 field

This 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 method

A call to

notify() or

notifyAll() was made without any (apparent)

accompanying modification to mutable object state. In general,

calling a notify method on a monitor is done because some condition

another thread is waiting for has become true. However, for the

condition to be meaningful, it must involve a heap object that is

visible to both threads.

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 method

This method calls

notify() rather than

notifyAll(). Java monitors are

often used for multiple conditions. Calling

notify() only wakes up one

thread, meaning that the thread woken up might not be the one waiting

for the condition that the caller just satisfied.

RS: Class's readObject() method is synchronized

This serializable class defines a

readObject() which is

synchronized. By definition, an object created by deserialization is

only reachable by one thread, and thus there is no need for

readObject()

to be synchronized. If the

readObject() method itself is causing the

object to become visible to another thread, that is an example of very

dubious coding style.

Ru: Invokes run on a thread (did you mean to start it

instead?)

This method explicitly invokes

run() on an object. In general,

classes implement the

Runnable interface because they are going to have

their

run() method invoked in a new thread, in which case

()

is the right method to call.

SC: Constructor invokes ()

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 field

This 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 method

This 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 method

This method contains a call to

() which is not

guarded by conditional control flow. If the condition that the method

intends to wait for has already happened, the thread could wait

indefinitely.

VO: A volatile reference to an array doesn't treat the array

elements as volatile

This 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 rent

(provided in Java 5.0).

WS: Class's writeObject() method is synchronized but nothing

else is

This class has a

writeObject() method which is synchronized; however, no

other method of the class is synchronized.

Wa: Wait not in loop in method

This method contains a call to

() which is not in a

loop. If the monitor is used for multiple conditions, the condition

the caller intended to wait for might not be the one that actually

occurred.

Dm: Method invokes dubious Boolean constructor; use

f(...) instead

Creating new instances of

n wastes memory, since

Boolean

objects are immutable and there are only two useful values of this

type. Use the

f() method to create

Boolean objects instead.

Dm: Explicit garbage collection; extremely dubious except in

benchmarking code

Code 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 argument

Using the

(String) constructor wastes memory because the

object so constructed will be functionally indistinguishable from the

String passed as a parameter. Just use the argument

String directly.

Dm: Method invokes dubious (""); use

() == 0 instead

An 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

String

Calling

ng() is just a redundant operation. Just use the

String.

Dm: Method invokes dubious new String() constructor; just use

""

Creating a new

object using the no-argument constructor

wastes memory because the object so created will be functionally

indistinguishable from the empty string constant

"". Java guarantees

that identical string constants will be represented by the same

String

object. Therefore, you should just use the empty string constant

directly.

FI: Empty finalizer should be deleted

Empty

finalize() methods are useless, so they should be deleted.

FI: Finalizer does nothing but call superclass finalizer

The only thing this

finalize() method does is call the superclass's

finalize() method, making it redundant. Delete it.

ITA: Method uses toArray() with zero-length array argument

This 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

y(new Foo[()])

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 loop

The 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 < ; ++i) {

s = s + field[i];

}

// This is better

StringBuffer buf = new StringBuffer();

for (int i = 0; i < ; ++i) {

(field[i]);

}

String s = ng();

SIC: Should be a static inner class

This 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 class

This 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 class

This 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 called

This 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 field

This field is never read. Consider removing it from the class.

UuF: Unused field

This field is never used. Consider removing it from the class.