FindBugs Report

Project Information

Project: <<unnamed project>>

FindBugs version: 0.9.5

Code analyzed:

Contents

Summary

Warning Type Number
Correctness Warnings 22
Internationalization Warnings 0
Multithreaded Correctness Warnings 0
Malicious Code Vulnerability Warnings 42
Performance Warnings 0
Style Warnings 9
Total 73

Warnings

Click on a warning row to see full context information.

Correctness Warnings

Code  Warning
DE
EC
EC
EC
EC
HE
HE
HE
HE
HE
HE
HE
HE
HE
HE
IL
IL
MF
Nm
Se
Se
Se

Internationalization Warnings

Code  Warning

Multithreaded Correctness Warnings

Code  Warning

Malicious Code Vulnerability Warnings

Code  Warning
MS
MS
MS
MS
MS
MS
MS
MS
MS
MS
MS
MS
MS
MS
MS
MS
MS
MS
MS
MS
MS
MS
MS
MS
MS
MS
MS
MS
MS
MS
MS
MS
MS
MS
MS
MS
MS
MS
MS
MS
MS
MS

Performance Warnings

Code  Warning

Style Warnings

Code  Warning
DLS
DLS
DLS
DLS
DLS
DLS
DLS
DLS
ST

Details

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

DLS_DEAD_LOCAL_STORE: Dead store to local variable

This instruction assigns a value to a local variable, but the value is not read by any subsequent instruction. Often, this indicates an error, because the value computed is never used.

Note that Sun's javac compiler often generates dead stores for final local variables. Because FindBugs is a bytecode-based tool, there is no easy way to eliminate these false positives.

EC_UNRELATED_TYPES: Call to equals() comparing different types

This method calls equals(Object) on two references of different class types with no common subclasses. Therefore, the objects being compared are unlikely to be members of the same class at runtime (unless some application classes were not analyzed, or dynamic class loading can occur at runtime). According to the contract of equals(), objects of different classes should always compare as unequal; therefore, according to the contract defined by java.lang.Object.equals(Object), the result of this comparison will always be false at runtime.

EC_UNRELATED_CLASS_AND_INTERFACE: Call to equals() comparing unrelated class and interface

This method calls equals(Object) on two references, one of which is a class and the other an interface, where neither the class nor any of its non-abstract subclasses implement the interface. Therefore, the objects being compared are unlikely to be members of the same class at runtime (unless some application classes were not analyzed, or dynamic class loading can occur at runtime). According to the contract of equals(), objects of different classes should always compare as unequal; therefore, according to the contract defined by java.lang.Object.equals(Object), the result of this comparison will always be false at runtime.

HE_EQUALS_USE_HASHCODE: Class defines equals() and uses Object.hashCode()

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 that equal objects must have equal hashcodes.

If you don't think instances of this class will ever be inserted into a HashMap/HashTable, the recommended hashCode implementation to use is:

public int hashCode() {
  assert false : "hashCode not designed";
  return 42; // any arbitrary constant will do 
  }

IL_INFINITE_RECURSIVE_LOOP: An apparent infinite recursive loop.

This method unconditionally invokes itself. This would seem to indicate an infinite recursive loop that will result in a stack overflow.

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

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

NM_VERY_CONFUSING: Very confusing method names

The referenced methods have names that differ only by capitalization.

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

ST_WRITE_TO_STATIC_FROM_INSTANCE_METHOD: Write to static field from instance method

This instance method writes to a static field. This is tricky to get correct if multiple instances are being manipulated, and generally bad practice.

The following classes needed for analysis were missing: javax.transaction.SystemException javax.transaction.TransactionManager javax.transaction.UserTransaction javax.transaction.NotSupportedException javax.transaction.RollbackException javax.transaction.HeuristicMixedException javax.transaction.HeuristicRollbackException javax.transaction.Synchronization javax.transaction.Transaction Warnings generated: 73 Missing classes: 9