Why is this an issue?
When iterating over an Iterable with a for loop, the iteration variable could have the same type as the type returned by
the iterator (the item type of the Iterable). This rule reports when a supertype of the item type is used for the variable instead, but
the variable is then explicitly downcast in the loop body.
Using explicit type casts instead of leveraging the language’s type system is a bad practice. It disables static type checking by the compiler for
the cast expressions, but potential errors will throw a ClassCastException during runtime instead.
How to fix it
Code examples
Noncompliant code example
When declaring the iteration variable, use the item type for it instead of a supertype. Remove the explicit downcasts in the loop body.
for (Object item : getPersons()) { // Noncompliant, iteration element is implicitly upcast here
Person person = (Person) item; // Noncompliant, item is explicitly downcast here
person.getAddress();
}
Compliant solution
for (Person person : getPersons()) { // Compliant
person.getAddress();
}
Noncompliant code example
Alternatively, use the var keyword to automatically infer the variable type (since Java 10).
for (Object item : getPersons()) { // Noncompliant, iteration element is implicitly upcast here
Person person = (Person) item; // Noncompliant, item is explicitly downcast here
person.getAddress();
}
Compliant solution
for (var person : getPersons()) { // Compliant
person.getAddress();
}
Compliant solution
The implicit upcast in the loop header is not reported when there is no downcast in the loop body.
for (Object item : getPersons()) { // Compliant
System.out.println(item);
}
