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 (argv.length == 1);
System.out.println(\
UI: Usage of GetResource may be unsafe if class is extended
Calling this.getClass().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
http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html.
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 \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 \which has more accurate ways of detecting locked vs. unlocked accesses than the older \
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 Thread.start() is the right method to call.
SC: Constructor invokes Thread.start()
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