## 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);
    }