Java 8 Iterable.forEach() vs foreach loop

The main advantage from my point of view is that the implementation of what is to be done within the loop can be defined without having to decide if it will be executed in parallel or sequential

If you want your loop to be executed in parallel you could simply write

 joins.parallelStream().forEach((join) -> mIrc.join(mSession, join));

You will have to write some extra code for thread handling etc.

Can't use non-final variables . So, code like the following can't be turned into a forEach lambda:

Object prev = null;
for(Object curr : list)
{
    if( prev != null )
        foo(prev, curr);
    prev = curr;
}

Can't handle checked exceptions . Lambdas aren't actually forbidden from throwing checked exceptions, but common functional interfaces like Consumer don't declare any. Therefore, any code that throws checked exceptions must wrap them in try-catch or Throwables.propagate() . But even if you do that, it's not always clear what happens to the thrown exception. It could get swallowed somewhere in the guts of forEach()

Limited flow-control . A return in a lambda equals a continue in a for-each, but there is no equivalent to a break . It's also difficult to do things like return values, short circuit, or set flags (which would have alleviated things a bit, if it wasn't a violation of the no non-final variables rule). "This is not just an optimization, but critical when you consider that some sequences (like reading the lines in a file) may have side-effects, or you may have an infinite sequence."

Might execute in parallel , which is a horrible, horrible thing for all but the 0.1% of your code that needs to be optimized. Any parallel code has to be thought through (even if it doesn't use locks, volatiles, and other particularly nasty aspects of traditional multi-threaded execution). Any bug will be tough to find.

Might hurt performance , because the JIT can't optimize forEach()+lambda to the same extent as plain loops, especially now that lambdas are new. By "optimization" I do not mean the overhead of calling lambdas (which is small), but to the sophisticated analysis and transformation that the modern JIT compiler performs on running code.

If you do need parallelism, it is probably much faster and not much more difficult to use an ExecutorService . Streams are both automagical (read: don't know much about your problem) and use a specialized (read: inefficient for the general case) parallelization strategy (fork-join recursive decomposition).

Makes debugging more confusing , because of the nested call hierarchy and, god forbid, parallel execution. The debugger may have issues displaying variables from the surrounding code, and things like step-through may not work as expected.

Streams in general are more difficult to code, read, and debug . Actually, this is true of complex "fluent" APIs in general. The combination of complex single statements, heavy use of generics, and lack of intermediate variables conspire to produce confusing error messages and frustrate debugging. Instead of "this method doesn't have an overload for type X" you get an error message closer to "somewhere you messed up the types, but we don't know where or how." Similarly, you can't step through and examine things in a debugger as easily as when the code is broken into multiple statements, and intermediate values are saved to variables. Finally, reading the code and understanding the types and behavior at each stage of execution may be non-trivial.

Sticks out like a sore thumb . The Java language already has the for-each statement. Why replace it with a function call? Why encourage hiding side-effects somewhere in expressions? Why encourage unwieldy one-liners? Mixing regular for-each and new forEach willy-nilly is bad style. Code should speak in idioms (patterns that are quick to comprehend due to their repetition), and the fewer idioms are used the clearer the code is and less time is spent deciding which idiom to use (a big time-drain for perfectionists like myself!).

Atomically iterating over a synchronized list . Prior to this, a list generated with Collections.synchronizedList() was atomic with respect to things like get or set, but was not thread-safe when iterating.

Parallel execution (using an appropriate parallel stream) . This saves you a few lines of code vs using an ExecutorService, if your problem matches the performance assumptions built into Streams and Spliterators.

Specific containers which , like the synchronized list, benefit from being in control of iteration (although this is largely theoretical unless people can bring up more examples)

Calling a single function more cleanly by using forEach() and a method reference argument (ie, list.forEach (obj::someMethod) ). However, keep in mind the points on checked exceptions, more difficult debugging, and reducing the number of idioms you use when writing code.

To make your code more explicit: As described above, Iterable#forEach can make your code more explicit and readable in some situations.

To make your code more extensible and maintainable: Using a function as the body of a loop allows you to replace this function with different implementations (see Strategy Pattern). You could eg easily replace the lambda expression with a method call, that may be overwritten by sub-classes:

joins.forEach(getJoinStrategy());

Then you could provide default strategies using an enum, that implements the functional interface. This not only makes your code more extensible, it also increases maintainability because it decouples the loop implementation from the loop declaration.

To make your code more debuggable: Seperating the loop implementation from the declaration can also make debugging more easy, because you could have a specialized debug implementation, that prints out debug messages, without the need to clutter your main code with if(DEBUG)System.out.println() . The debug implementation could eg be a delegate, that decorates the actual function implementation.

To optimize performance-critical code: Contrary to some of the assertions in this thread, Iterable#forEach does already provide better performance than a traditional for-each loop, at least when using ArrayList and running Hotspot in "-client" mode. While this performance boost is small and negligible for most use cases, there are situations, where this extra performance can make a difference. Eg library maintainers will certainly want to evaluate, if some of their existing loop implementations should be replaced with Iterable#forEach .

To back this statement up with facts, I have done some micro-benchmarks with Caliper. Here is the test code (latest Caliper from git is needed):

@VmOptions("-server")
public class Java8IterationBenchmarks {

    public static class TestObject {
        public int result;
    }

    public @Param({"100", "10000"}) int elementCount;

    ArrayList<TestObject> list;
    TestObject[] array;

    @BeforeExperiment
    public void setup(){
        list = new ArrayList<>(elementCount);
        for (int i = 0; i < elementCount; i++) {
            list.add(new TestObject());
        }
        array = list.toArray(new TestObject[list.size()]);
    }

    @Benchmark
    public void timeTraditionalForEach(int reps){
        for (int i = 0; i < reps; i++) {
            for (TestObject t : list) {
                t.result++;
            }
        }
        return;
    }

    @Benchmark
    public void timeForEachAnonymousClass(int reps){
        for (int i = 0; i < reps; i++) {
            list.forEach(new Consumer<TestObject>() {
                @Override
                public void accept(TestObject t) {
                    t.result++;
                }
            });
        }
        return;
    }

    @Benchmark
    public void timeForEachLambda(int reps){
        for (int i = 0; i < reps; i++) {
            list.forEach(t -> t.result++);
        }
        return;
    }

    @Benchmark
    public void timeForEachOverArray(int reps){
        for (int i = 0; i < reps; i++) {
            for (TestObject t : array) {
                t.result++;
            }
        }
    }
}

And here are the results:

To provide optional support for parallel execution: It has already been said here, that the possibility to execute the functional interface of Iterable#forEach in parallel using streams, is certainly an important aspect. Since Collection#parallelStream() does not guarantee, that the loop is actually executed in parallel, one must consider this an optional feature. By iterating over your list with list.parallelStream().forEach(...); , you explicitly say: This loop supports parallel execution, but it does not depend on it. Again, this is a feature and not a deficit!

By moving the decision for parallel execution away from your actual loop implementation, you allow optional optimization of your code, without affecting the code itself, which is a good thing. Also, if the default parallel stream implementation does not fit your needs, no one is preventing you from providing your own implementation. You could eg provide an optimized collection depending on the underlying operating system, on the size of the collection, on the number of cores, and on some preference settings:

public abstract class MyOptimizedCollection<E> implements Collection<E>{
    private enum OperatingSystem{
        LINUX, WINDOWS, ANDROID
    }
    private OperatingSystem operatingSystem = OperatingSystem.WINDOWS;
    private int numberOfCores = Runtime.getRuntime().availableProcessors();
    private Collection<E> delegate;

    @Override
    public Stream<E> parallelStream() {
        if (!System.getProperty("parallelSupport").equals("true")) {
            return this.delegate.stream();
        }
        switch (operatingSystem) {
            case WINDOWS:
                if (numberOfCores > 3 && delegate.size() > 10000) {
                    return this.delegate.parallelStream();
                }else{
                    return this.delegate.stream();
                }
            case LINUX:
                return SomeVerySpecialStreamImplementation.stream(this.delegate.spliterator());
            case ANDROID:
            default:
                return this.delegate.stream();
        }
    }
}

The nice thing here is, that your loop implementation doesn't need to know or care about these details.