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 java.lang.Object, 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 java.lang.Object, 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 \question\File.listFiles() 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 java.lang.Integer, java.lang.Float, 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 InputStream.read()
This method ignores the return value of one of the variants of
java.io.InputStream.read() 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 InputStream.skip()
This method ignores the return value of java.io.InputStream.skip() 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 java.lang.Object, 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 String.class 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.