FindBugs Report

Project Information

Project:

FindBugs version: 3.0.1

Code analyzed:



Metrics

6536 lines of code analyzed, in 177 classes, in 12 packages.

Metric Total Density*
High Priority Warnings 4 0.61
Medium Priority Warnings 9 1.38
Total Warnings 13 1.99

(* Defects per Thousand lines of non-commenting source statements)



Contents

Summary

Warning Type Number
Bad practice Warnings 3
Correctness Warnings 1
Internationalization Warnings 2
Multithreaded correctness Warnings 4
Performance Warnings 2
Dodgy code Warnings 1
Total 13

Warnings

Click on a warning row to see full context information.

Bad practice Warnings

Code Warning
Eq org.apache.kafka.connect.runtime.distributed.DistributedHerder$HerderRequest defines compareTo(DistributedHerder$HerderRequest) and uses Object.equals()
Eq org.apache.kafka.connect.runtime.rest.entities.ConnectorStateInfo$TaskState defines compareTo(ConnectorStateInfo$TaskState) and uses Object.equals()
ES Comparison of String objects using == or != in org.apache.kafka.connect.runtime.AbstractHerder.convertConfigKey(ConfigDef$ConfigKey)

Correctness Warnings

Code Warning
RV Return value of java.util.concurrent.CountDownLatch.await(long, TimeUnit) ignored in org.apache.kafka.connect.runtime.WorkerSourceTask.execute()

Internationalization Warnings

Code Warning
Dm Found reliance on default encoding in org.apache.kafka.connect.runtime.AbstractHerder.trace(Throwable): new java.io.PrintStream(OutputStream)
Dm Found reliance on default encoding in org.apache.kafka.connect.runtime.rest.RestServer.httpRequest(String, String, Object, TypeReference): String.getBytes()

Multithreaded correctness Warnings

Code Warning
IS Inconsistent synchronization of org.apache.kafka.connect.storage.OffsetStorageWriter.currentFlushId; locked 83% of time
IS Inconsistent synchronization of org.apache.kafka.connect.storage.OffsetStorageWriter.toFlush; locked 75% of time
UW Unconditional wait in org.apache.kafka.connect.tools.SchemaSourceTask.poll()
Wa Wait not in loop in org.apache.kafka.connect.tools.SchemaSourceTask.poll()

Performance Warnings

Code Warning
Bx Primitive boxed just to call toString in new org.apache.kafka.connect.runtime.Worker(String, Time, ConnectorFactory, WorkerConfig, OffsetBackingStore)
Bx Primitive is boxed to call Integer.compareTo(Integer): use Integer.compare(int, int) instead

Dodgy code Warnings

Code Warning
SF Switch statement found in org.apache.kafka.connect.runtime.WorkerConnector.pause() where one case falls through to the next case

Details

DM_BOXED_PRIMITIVE_FOR_COMPARE: Boxing a primitive to compare

A boxed primitive is created just to call compareTo method. It's more efficient to use static compare method (for double and float since Java 1.4, for other primitive types since Java 1.7) which works on primitives directly.

DM_BOXED_PRIMITIVE_TOSTRING: Method allocates a boxed primitive just to call toString

A boxed primitive is allocated just to call toString(). It is more effective to just use the static form of toString which takes the primitive value. So,

Replace...With this...
new Integer(1).toString()Integer.toString(1)
new Long(1).toString()Long.toString(1)
new Float(1.0).toString()Float.toString(1.0)
new Double(1.0).toString()Double.toString(1.0)
new Byte(1).toString()Byte.toString(1)
new Short(1).toString()Short.toString(1)
new Boolean(true).toString()Boolean.toString(true)

DM_DEFAULT_ENCODING: Reliance on default encoding

Found a call to a method which will perform a byte to String (or String to byte) conversion, and will assume that the default platform encoding is suitable. This will cause the application behaviour to vary between platforms. Use an alternative API and specify a charset name or Charset object explicitly.

EQ_COMPARETO_USE_OBJECT_EQUALS: Class defines compareTo(...) and uses Object.equals()

This class defines a compareTo(...) method but inherits its equals() method from java.lang.Object. Generally, the value of compareTo should return zero if and only if equals returns true. If this is violated, weird and unpredictable failures will occur in classes such as PriorityQueue. In Java 5 the PriorityQueue.remove method uses the compareTo method, while in Java 6 it uses the equals method.

From the JavaDoc for the compareTo method in the Comparable interface:

It is strongly recommended, but not strictly required that (x.compareTo(y)==0) == (x.equals(y)). Generally speaking, any class that implements the Comparable interface and violates this condition should clearly indicate this fact. The recommended language is "Note: this class has a natural ordering that is inconsistent with equals."

ES_COMPARING_STRINGS_WITH_EQ: Comparison of String objects using == or !=

This code compares java.lang.String objects for reference equality using the == or != operators. Unless both strings are either constants in a source file, or have been interned using the String.intern() method, the same string value may be represented by two different String objects. Consider using the equals(Object) method instead.

IS2_INCONSISTENT_SYNC: 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

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.

RV_RETURN_VALUE_IGNORED: Method ignores return value

The return value of this method should be checked. One common cause of this warning is to invoke a method on an immutable object, thinking that it updates the object. For example, in the following code fragment,

String dateString = getHeaderField(name);
dateString.trim();

the programmer seems to be thinking that the trim() method will update the String referenced by dateString. But since Strings are immutable, the trim() function returns a new String value, which is being ignored here. The code should be corrected to: 

String dateString = getHeaderField(name);
dateString = dateString.trim();

SF_SWITCH_FALLTHROUGH: Switch statement found where one case falls through to the next case

This method contains a switch statement where one case branch will fall through to the next case. Usually you need to end this case with a break or return.

UW_UNCOND_WAIT: Unconditional wait

This method contains a call to java.lang.Object.wait() which is not guarded by conditional control flow.  The code should verify that condition it intends to wait for is not already satisfied before calling wait; any previous notifications will be ignored.

WA_NOT_IN_LOOP: Wait not in loop

This method contains a call to java.lang.Object.wait() 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.