The enhanced for
statement introduced in Java 5 (also known as the for-each idiom) is primarily used for iterating over collections of objects. Unlike the basic for
statement, assignments to the loop variable fail to affect the loop's iteration order over the underlying set of objects. Consequently, assignments to the loop variable can have an effect other than what is intended by the developer. This provides yet another reason to avoid assigning to the loop variable in a for
loop.is designed for iteration through Collections and arrays.
The Java Language Specification (JLS) provides the following example of the enhanced for
statement in §14 As detailed in the JLS, [§14.14.2, "The Enhanced For Statement" |http://java.sun.com/docs/books/jls/third_edition/html/statements.html#14.14.2] \[[JLS 2005|AA. References#JLS 05]\]: Wiki Markup for
Statement" [JLS 2014]:
The enhanced for statement
An enhanced
for
statement of the form
Code Block for (ObjType obj : someIterableItem) { // ... }
is equivalent to a basic for loop statement of the form:
Code Block for (IteratorI myIterator#i = someIterableItemExpression.iterator(); myIterator#i.hasNext(); ) { {VariableModifier} ObjTypeTargetType objIdentifier = myIterator (TargetType) #i.next(); // ... } Statement }#i is an automatically generated identifier that is distinct from any other identifiers (automatically generated or otherwise) that are in scope...at the point where the enhanced for statement occurs.
Unlike the basic for
statement, assignments to the loop variable fail to affect the loop's iteration order over the underlying set of objects. Consequently, an assignment to the loop variable is equivalent to modifying a variable local to the loop body whose initial value is the object referenced by the loop iterator. This modification is not necessarily erroneous , but can obscure the loop functionality or indicate a misunderstanding of the underlying implementation of the enhanced for
statement.
Declare all enhanced for
statement loop variables final. The final
declaration causes Java compilers to flag and reject any assignments made to the loop variable.
Noncompliant Code Example
This noncompliant code example attempts to process a collection of objects integers using an enhanced for
loop. It further intends to skip processing modify one item in the collection .for processing:
Code Block | |||||
---|---|---|---|---|---|
| |||||
List<Integer> list = Arrays.asList(new Integer[] {13, 14, 15}); boolean first = true; System.out.println("Processing list..."); for (Integer i: list Collection<ProcessObj> processThese = // ... for (ProcessObj processMe: processThese) { if (someConditionfirst) { // found the itemfirst to= skipfalse; someConditioni = false new Integer(99); } processMe = processMe.getNext();System.out.println(" New item: " + i); // attempt to skip to next item } processMe.doTheProcessing(); // process the object } |
The attempt to skip to the next item appears to succeed because the assignment is successful and the value of processMe
is updated. Unlike a basic for
loop, however, the assignment leaves the overall iteration order of the loop unchanged. Consequently, the object following the skipped object is processed twice.
...
Process i
}
System.out.println("Modified list?");
for (Integer i: list) {
System.out.println("List item: " + i);
}
|
However, this code does not actually modify the list, as shown by the program's output:
Processing list...
New item: 99
New item: 14
New item: 15
Modified list?
List item: 13
List item: 14
List item: 15
Compliant Solution
Declaring i
to be final mitigates this problem by causing the compiler to fail to permit i
to be assigned a new value:
Code Block | ||||
---|---|---|---|---|
| ||||
// ...
for (final Integer i: list) {
// ...
|
Compliant Solution
This compliant solution correctly processes each object in the collection no more than once.processes the "modified" list but leaves the actual list unchanged:
Code Block | ||||
---|---|---|---|---|
| ||||
Collection<ProcessObj> processThese = // ... for (final ProcessObjInteger processMei: processTheselist) { ifInteger (someCondition)item { // found the item to skip= i; if (first) { someConditionfirst = false; continue;item //= skip by continuing to next iterationnew Integer(99); } processMeSystem.out.doTheProcessing(println(" New item: " + item); // processProcess the objectitem } // ... |
Risk Assessment
Assignments to the loop variable of an enhanced for
loop (for-each
idiom) fail to affect the overall iteration order, lead to programmer confusion, and can leave data in a fragile or inconsistent state.
Rule | Severity | Likelihood | Remediation Cost | Priority | Level |
---|---|---|---|---|---|
DCL02-J |
Low |
Unlikely |
Low | P3 | L3 |
Automated Detection
...
This rule is easily enforced with static analysis.
Bibliography
Tool | Version | Checker | Description | ||||||
---|---|---|---|---|---|---|---|---|---|
Parasoft Jtest |
| CERT.DCL02.ITMOD | Do not modify collection while iterating over it |
Bibliography
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="34186a16-04ea-46e4-b1d5-d6c8ed6fe3e5"><ac:plain-text-body><![CDATA[
[[JLS 2005
AA. References#JLS 05]]
[JLS 2014] |
http://java.sun.com/docs/books/jls/third_edition/html/statements.html#14.14.2]
]]></ac:plain-text-body></ac:structured-macro>
...
01. Declarations and Initialization (DCL) 02. Expressions (EXP)