Is there a way to access an iteration-counter in Java's for-each loop?

Question

Is there a way in Java's for-each loop

for(String s : stringArray) {
  doSomethingWith(s);
}

to find out how often the loop has already been processed?

Aside from using the old and well-known for(int i=0; i < boundary; i++) - loop, is the construct

int i = 0;
for(String s : stringArray) {
  doSomethingWith(s);
  i++;
}

the only way to have such a counter available in a for-each loop?

Solution 1

No, but you can provide your own counter.

The reason for this is that the for-each loop internally does not have a counter; it is based on the Iterable interface, i.e. it uses an Iterator to loop through the "collection" - which may not be a collection at all, and may in fact be something not at all based on indexes (such as a linked list).

Solution 2

There is another way.

Given that you write your own Index class and a static method that returns an Iterable over instances of this class you can

for (Index<String> each: With.index(stringArray)) {
    each.value;
    each.index;
    ...
}

Where the implementation of With.index is something like

class With {
    public static <T> Iterable<Index<T>> index(final T[] array) {
        return new Iterable<Index<T>>() {
            public Iterator<Index<T>> iterator() {
                return new Iterator<Index<T>>() {
                    index = 0;
                    public boolean hasNext() { return index < array.size }
                    public Index<T> next() { return new Index(array[index], index++); }
                    ...
                }
            }
        }
    }
}

Solution 3

The easiest solution is to just run your own counter thus:

int i = 0;
for (String s : stringArray) {
    doSomethingWith(s, i);
    i++;
}

The reason for this is because there's no actual guarantee that items in a collection (which that variant of for iterates over) even have an index, or even have a defined order (some collections may change the order when you add or remove elements).

See for example, the following code:

import java.util.*;

public class TestApp {
  public static void AddAndDump(AbstractSet<String> set, String str) {
    System.out.println("Adding [" + str + "]");
    set.add(str);
    int i = 0;
    for(String s : set) {
        System.out.println("   " + i + ": " + s);
        i++;
    }
  }

  public static void main(String[] args) {
    AbstractSet<String> coll = new HashSet<String>();
    AddAndDump(coll, "Hello");
    AddAndDump(coll, "My");
    AddAndDump(coll, "Name");
    AddAndDump(coll, "Is");
    AddAndDump(coll, "Pax");
  }
}

When you run that, you can see something like:

Adding [Hello]
   0: Hello
Adding [My]
   0: Hello
   1: My
Adding [Name]
   0: Hello
   1: My
   2: Name
Adding [Is]
   0: Hello
   1: Is
   2: My
   3: Name
Adding [Pax]
   0: Hello
   1: Pax
   2: Is
   3: My
   4: Name

indicating that, rightly so, order is not considered a salient feature of a set.

There are other ways to do it without a manual counter but it's a fair bit of work for dubious benefit.

Solution 4

Using lambdas and functional interfaces in Java 8 makes creating new loop abstractions possible. I can loop over a collection with the index and the collection size:

List<String> strings = Arrays.asList("one", "two","three","four");
forEach(strings, (x, i, n) -> System.out.println("" + (i+1) + "/"+n+": " + x));

Which outputs:

1/4: one
2/4: two
3/4: three
4/4: four

Which I implemented as:

   @FunctionalInterface
   public interface LoopWithIndexAndSizeConsumer<T> {
       void accept(T t, int i, int n);
   }
   public static <T> void forEach(Collection<T> collection,
                                  LoopWithIndexAndSizeConsumer<T> consumer) {
      int index = 0;
      for (T object : collection){
         consumer.accept(object, index++, collection.size());
      }
   }

The possibilities are endless. For example, I create an abstraction that uses a special function just for the first element:

forEachHeadTail(strings, 
                (head) -> System.out.print(head), 
                (tail) -> System.out.print(","+tail));

Which prints a comma separated list correctly:

one,two,three,four

Which I implemented as:

public static <T> void forEachHeadTail(Collection<T> collection, 
                                       Consumer<T> headFunc, 
                                       Consumer<T> tailFunc) {
   int index = 0;
   for (T object : collection){
      if (index++ == 0){
         headFunc.accept(object);
      }
      else{
         tailFunc.accept(object);
      }
   }
}

Libraries will begin to pop up to do these sorts of things, or you can roll your own.

Solution 5

Java 8 introduced the Iterable#forEach() / Map#forEach() method, which is more efficient for many Collection / Map implementations compared to the "classical" for-each loop. However, also in this case an index is not provided. The trick here is to use AtomicInteger outside the lambda expression. Note: variables used within the lambda expression must be effectively final, that is why we cannot use an ordinary int.

final AtomicInteger indexHolder = new AtomicInteger();
map.forEach((k, v) -> {
    final int index = indexHolder.getAndIncrement();
    // use the index
});

View more solutions

Comments

[Val]

Another pity is that you cannot use the loop variable outside the loop, Type var = null; for (var : set) dosomething; if (var != null) then ...

[rmuller]

@Val unless the reference is effective final. See my answer for how to use this feature

[Brett]

(I've fixed that bug in the question.)

[Kosi2801]

With a performance approaching O(n²) for the whole loop it's very hard to imagine even a few situations where this would be superior to anything else. Sorry.

[mR_fr0g]

Neat idea. I would have upvoted had it not been for short lived object creation of the Index class.

[Sandeep Chauhan]

@mR_fr0g don't worry, I benchmarked this and creating all these objects is not any slower than reusing the same object for each iteration. The reason is that all these objects are allocated in eden space only and never life long enough to reach the heap. So allocating them is as fast as e.g. allocating local variables.

[Val]

@akuhn Wait. Eden space does not mean that no GC is reaquired. Quite the opposite, you need to invoke constructor, scan sooner with GC and finalize. This not only loads CPU but also invalidates the cache all the time. Nothing like this is necessary for local variables. Why do you say that this is "the same"?

[Sandeep Chauhan]

@Val objects without constructor are allocated by incrementing a pointer. That's all. One instruction. And since none of these objects escapes eden, GC just resets that pointer. At least it used to do that 4 years ago. If you are curious, you can look at the assembly code using the PrintOptoAssembly option.

[Val]

oreilly.com/catalog/javapt/chapter/ch04.html says Reduce the number of temporary objects being used, especially in loops. It also says Be aware of the default values that Java initializes Object to null, int to 0, bool to false. I could not find anything by PrintOptoAssembly but I do not think that these initializations can be as simple as pointer increment. Similarly, you need to scan the whole overflown memory to determine the unreferenced objects. I do not believe that GC is as cheap as pointer decrement.

[Sandeep Chauhan]

@val that book is from 2000, VM technology has improved quite a bit since.

[Val]

Do you mean that VM improved by not initializing the variables? By not checking which object are referred which are not? How can you improve to become a magician? Is it improved by silencing the issues I raise?

[Sandeep Chauhan]

@Val you're persistent :) Each thread has a thread local eden space. Our With objects are allocated on eden by incrementing a pointer. No initialization needed since the constructor sets all fields. The VM keeps a list of pointers that escaped eden (as far I recall) and our case that list is empty so gc on eden simply resets that pointer. Allocating object used to be expensive in 2000, today it is one of the cheapest operations in a JVM. For example, object pooling used to be a good idea back then but its is very bad idea today.

[Val]

If you call the constructor to initialize the fields, this does not mean that it is not called (as you stated before) or no time is wasted initializing the fields. You do not even understand that keeping a list of pointers does not tell you whether object is in use or not. Your argument is just spreading the gossip assurance. It contradicts to pure logic and itself. This is not technical and hardly instills confidence. I do not think that java spec has changed since 2000 and logic says that there are aspects that cannot be just optimized. Just confirm that, and I'll back off.

[Bill K]

If you are worried about performance of short lived objects like this, you are doing it wrong. Performance should be the LAST thing to worry about... readability the first. This is actually a pretty good construct.

[Joshua Pinter]

This still seems to be the clearest solution, even with List and Iterable interfaces.

[Joshua Pinter]

Curious, is there any benefit of using this over the, seemingly, clearer i=0; i++; approach?

[Eric Woodruff]

I was going to say I don't really understand the need to debate when the Index instance can be created once and reused/updated, just to moot the argument and make everyone happy. However, in my measurements, the version that creates a new Index() each time performed more than twice as fast on my machine, about equal to a native iterator running the same iterations.

[Nicholas DiPiazza]

Ruby has a construct for this and Java should get it too... for(int idx=0, String s; s : stringArray; ++idx) doSomethingWith(s, idx);

[gcedo]

I guess if you need to use again the i index after doSomething in the for scope.

[saywhatnow]

FYI @NicholasDiPiazza there is an each_with_index loop method for Enumerable in Ruby. See apidock.com/ruby/Enumerable/each_with_index

[Nicholas DiPiazza]

@saywhatnow yeah that's what i meant sorry - not sure what i was smoking when i made the previous comment

[Kosi2801]

Be careful that this needs an .equals()-implementation of the Arrays objects which can identify a certain object uniquely. This is not the case for Strings, if a certain string is in the Array multiple times you will only get the index of the first occurence, even if you were already iterating on a later item with the same string.

[Manius]

Not a criticism of the post (it's "the cool way to do it" these days I guess), but I struggle to see how this is easier/better than a simple old school for loop: for (int i = 0; i < list.size(); i++) { } Even grandma could understand this and it's probably easier to type without the syntax and uncommon characters a lambda uses. Don't get me wrong, I love using lambdas for certain things (callback/event handler type of pattern) but I just can't understand the use in cases like this. Great tool, but using it all the time, I just can't do.

[Manius]

I suppose, some avoidance of off-by-one index over/underflows against the list itself. But there is the option posted above: int i = 0; for (String s : stringArray) { doSomethingWith(s, i); i++; }

[izogfif]

"The reason for this is that the for-each loop internally does not have a counter". Should be read as "Java developers didn't care to let programmer specify index variable with initial value inside for loop", something like for (int i = 0; String s: stringArray; ++i)

[Kosi2801]

Sorry, this is not answering the question. It's not about accessing the content but about a counter how often the loop already has been iterated.

[rumman0786]

Question was to find out the current index in the loop in a for-each style loop.

[Nareman Darwish]

Please provide your answer in a reproducible code format.

[Kosi2801]

This is exactly the way for which an alternative solution is wanted. The question is not about types but about possibilities to access the loop counter in a DIFFERENT way than counting manually.

[ashkanaral]

Atleast keep it here and rate up as it is a similar answer in my opinion. Thank you for explanations Kosl2801 and rumman0786

[ankur_rajput]

Why can't we maintain an index/counter for anything which is Iterable? LinkedList is not based on indexes but we still have ListIterator which maintains a counter internally while iterating on it. If we are iterating on something that means we have n number of items, be it any format/DS. Isn't it? Any example where an index can't be maintained will be helpful. Thanks.

[Adam Hughes]

100% it seems like after java8 anytime I put a forloop into a PR, everyone wants to remind me that there are a zillion alternatives. But this is readible, canonical and not susceptible to the problem in the first place