Suspicious code or possible bugs

Assignment has no effect

A statement such as x=x has been detected. This is usually a scoping error, and most likely to happen in constructors when the parameter names match the field names.

Solution: replace with this.x=x, if appropriate.

Severity level: 1

Accidental Assignment

An assignment to a boolean variable has been detected in an expression, e.g. if(haveSource=true) that was probably intended to be an equality check instead: if(haveSource==true).

Solution: change the assignment to a comparison, if appropriate

Severity level: 1

Method with constructor name

A method has the same name as the class, and may have been confused with constructor.

Solution: change to a constructor by removing the return type, if appropriate

Severity level: 1

Using equals() or == on Arrays

Both the equals() method and the == operator check for object identity only. In most cases however, the intention is to check if the arrays have the same content.

Solution: use java.util.Arrays.equals() to compare array content

Severity level: 1

Comparing strings with the == operator

Strings, like any other object, should be compared using the equals() method. In most cases, it is a programming error if they are not; the == operator can return false even for identical Strings, these situations are described in the JLS. Only Strings that are computable at compile time can be compared reliably with the == operator, Strings whose value is computed ar run-time must be uniquified using the intern() method to achieve the same result. In Java JDK 1.3 and later, the method String.equals() tests for reference equality before testing the more expensive by-value equality, so there is no performance improvement when the == operator is used, it just makes the code harder to maintain and to get correct.

Solution: use the equals() method to compare Strings

Severity level: 2

Comparing objects with the == operator

This is harmless if classes explicitly document this behavior, such as java.lang.Class, but can be a programming error that is hard to spot. Lint4j omits reporting many classes from the Java API, as well as ignoring comparisons with null and this, commonly used in equals() methods, to reduce the number of false positives.

Solution: prefer using the equals() method. It is a good idea to encapsulate the implementation decision that objects of a class can be compared using the == operator by testing for reference equality first in the equals method, avoiding a possibly costly by-value comparison.

Severity level: 4

Equality comparisons with floating point types

Floating point types are inherently imprecise. Using the operators == or != might not yield the expected result, and are especially dangerous in a loop.

Solution: consider using an interval

Severity level: 2

Immutable field could be static

Final fields that have object scope and are immutable should be elevated to class scope to reduce memory footprint.

Solution: declare the field static

Severity level: 2