Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Parasoft Jtest 2021.1

The enhanced for statement is designed for iteration through Collections and arrays

The The Java Language Specification (JLS) provides the following example of the enhanced for statement in §14.14.2, "The Enhanced for Statement" [JLS 2014]:

 

...

The

enhanced

for

statement

is

equivalent

to

a

basic

for

statement

of

the

form:

Code Block


for (I \#i = Expression.iterator(); \#i.hasNext(); ) {
    {VariableModifier} TargetType Identifier =
        (TargetType) #i.next();
    Statement
}
    
\#i is an automatically generated identifier that is distinct from any other identifiers (automatically generated or otherwise) that are in 

#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
bgColor#ffcccc
lang#FFCCCCjava
List<Integer> list = Arrays.asList(new Integer[] {13, 14, 15});
boolean first = true;

System.out.println("Processing list...");
for (Integer i: listCollection<ProcessObj> processThese = // ... 

for (ProcessObj processMe: processThese) {
  if (someConditionfirst) {
 // found the itemfirst to= skipfalse;
    someConditioni = false;
    processMe = processMe.getNext(); // 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.

...

 new Integer(99);
  }
  System.out.println(" New item: " + i);
  // 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
bgColor#ffcccc
langjava
// ...
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
bgColor#ccccff
langjava
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

Low

unlikely

Unlikely

low

Low

P3

L3

Automated Detection

...

ToolVersionCheckerDescription
Parasoft Jtest
Include Page
Parasoft_V
Parasoft_V
CERT.DCL02.ITMODDo not modify collection while iterating over it

Bibliography

 


...

Image Removed      01. Declarations and Initialization (DCL)      02. Expressions (EXP)Image Added Image Added Image Added