Documentation Preview

Compared to main:
This changeset changes 0 violations,
introduces 31 new violations, 0 new errors and 0 new configuration errors,
removes 0 violations, 0 errors and 0 configuration errors.

Regression Tester Report

(comment created at 2026-03-24 18:34:13+00:00 for 2e69d19)

The example from Spring shows that this is not applicable if there are any operations in the loop that change the iterable's length (using enhanced for would create an infinite loop or a ConcurrentModificationException):

int size = aliases.size();
for (int j = 0; j < size; j++) {
  List<Method> additional = mapping.aliasedBy.get(aliases.get(j));
  if (additional != null) {
	aliases.addAll(additional);
  }
}

Also what about reassigning?

void printFirst(int count) {
  int toPrint= array.length;
  if (toPrint > count) {
    toPrint = count;
  }
  for (int i=0; i< toPrint; i++) {
    System.out.println(array[i]);
  }
}

Also what about reassigning?

I think, if we fix this false negative, we should restrict it to a local variable, that is effectively final - means it is initialized with array.length/list.size() and never changed.

This is what the sample code in #6495 shows.

For the concurrent modification exception problem - this might be a false-positive, different issue. If there are more interactions other than list.get(i) or array[i] inside the for-loop, then we should not suggest to use a foreach loop.

Ok, partly - it would be a new false positive (one worm out of the can): Previously, we didn't consider such for loops, because the list.size() was declared in a variable (otherwise they would get a OOM when running the code, as the list is getting bigger and bigger). Now we consider this for loop, and then we should ignore it, because they call list.addAll() (see https://github.com/spring-projects/spring-framework/blob/v5.3.13/spring-core/src/main/java/org/springframework/core/annotation/AnnotationTypeMapping.java#L219 ).

@leemeii Could you do the following tasks?

• Recreated this PR from a separate feature branch and not your main branch, so that all your PRs are isolated
• Add the following test cases

    <test-code>
        <description>list is modified</description>
        <expected-problems>0</expected-problems>
        <code><![CDATA[
import java.util.List;

class Foo {
    void m(List<String> list) {
        // if this loop would be changed to foreach, it potentially would throw a ConcurrentModificationException
        int size = list.size();
        for (int j = 0; j < size; j++) {
            List<String> additional = getAdditional(list.get(j));
            if (additional != null) {
                list.addAll(additional);
            }
        }
    }

    void m2(List<String> list) {
        // if this loop would be changed to foreach, it potentially would throw a ConcurrentModificationException
        int size = list.size();
        for (int j = 0; j < size; j++) {
            List<String> additional = getAdditional(list.get(j));
            if (additional != null) {
                list.add(additional.get(0));
            }
        }
    }
}
]]></code>
    </test-code>

    <test-code>
        <description>size variable not effectively final</description>
        <expected-problems>0</expected-problems>
        <code><![CDATA[
class Foo {
    void printFirst(int count) {
        String[] array = null;
        int toPrint = array.length;
        if (toPrint > count) {
            toPrint = count;
        }
        for (int i = 0; i < toPrint; i++) {
            System.out.println(array[i]);
        }
    }
}
]]></code>
    </test-code>

• Try to fix the rule so that these additional test cases pass

Closing this now because of missing response. Feel free to recreate it.