Sun's official language guide for new JDK 5 features states that,

Iterating over a collection is uglier than it needs to be.

The for-each loop, or enhanced for loop, was introduced in JDK 5 to reduce some of the clutter, and possible errors, in iterating over collections. Nishanth Sastry summarizes key features of the enhanced for loop in a recent java.net article, Nuances of the Java 5.0 for-each Loop, concluding that:

In effect, the for-each loop is nothing more than syntactic sugar. It makes the code much easier to read, but provides no new core functionality. In fact, the Java Language Specification describes the meaning of the new for-each loop in terms of an equivalent basic for loop. Essentially, an intermediate Iterator of the right kind is created, and it is guaranteed to be an identifier different from all other user variables in the scope.

Sastry summarizes several features of the enhanced for-each loop:

• The for-each loop allows only one iteration variable, which precludes simultaneously iterating over two or more arrays or collections.
• Nested iteration is possible.
• Beware of auto-unboxing... Unless you are forced to use native types because of their support for arithmetic operations, it is preferable to use subclasses of Number (Integer, Double, etc.) in loop variables rather than the equivalent native types (int, double, etc.).
• Watch out for null pointers... This particularly insidious error happens because of the hidden compiler-generated call to get the iterator. To make the code robust ... preface the for-each loop with a check like:

      if (null != liszt) 
          for(int num : liszt)
              //for loop body...
  

• Iterating over varargs. Java 5.0 now allows a variable number of arguments of a single type to be passed in as the last parameter to a method. The compiler collects these varargs parameters into an array of that type. Typically, the body of the method treats the varargs as an array and iterates over them using a for-each loop.
• Do not modify the list during iteration.
• Consider returning an Iterable rather than a List. Even if you are not defining a custom iterator, if a method in your API is returning a List that is expected to be solely used in for-each loops, consider changing the return type to java.lang.Iterable instead. This effectively hides the details of the current implementation and allows for later optimizations such as lazy construction of each iterated item.
• When appropriate, implement java.util.RandomAccess to allow for compiler optimizations.

What do you think of the enhanced for loop? Do you routinely replace traditional for loops in old code with the enhanced for loop?