3 Replies Latest reply on Feb 22, 2009 12:44 AM by 3004

    why does ExecutorService.invokeAll() accept a Collection and return a List?

    843785
      in the java.util.concurrent.ExecutorService interface please consider:
      List<Future<T>> invokeAll(Collection<Callable<T>> tasks);
      a Collection has no duplicates, and
      (i think?) there is a one-to-one mapping between Callables and Futures, so why return a List ?

      further. a Collection does not have ordering, thus the ordering of the Futures must be arbitrary and meaningless ?
      and therefore a List is not the appropriate container class.
      Collection<Future<T>> invokeAll(Collection<Callable<T>> tasks);
      or*
      List<Future<T>> invokeAll(List<Callable<T>> tasks);
      seems more logical?
        • 1. Re: why does ExecutorService.invokeAll() accept a Collection and return a List?
          3004
          kogose wrote:
          in the java.util.concurrent.ExecutorService interface please consider:
          List<Future<T>> invokeAll(Collection<Callable<T>> tasks);
          a Collection has no duplicates,
          Not true. A Set has no dupes.
          and
          (i think?) there is a one-to-one mapping between Callables and Futures, so why return a List ?

          further. a Collection does not have ordering, thus the ordering of the Futures must be arbitrary and meaningless ?
          and therefore a List is not the appropriate container class.
          If you read the docs for that method, you'll see that the returned List will be in the same order as the iteration over the Collection provided.
          • 2. Re: why does ExecutorService.invokeAll() accept a Collection and return a List?
            843785
            thanks for putting me straight on the Collection interface...

            i did some testing on Set iterations as follows.

            case #1:
            Set<String> set = new HashSet<String>();
              for(int i = 0; i < 10; i++) {
                set.add(Integer.toString(i));
              }
            case #2:
            Set<String> set = new HashSet<String>();
            for(int i = 9; i >= 0; i--) {
              set.add(Integer.toString(i));
            }
            i did this on two different machines with different versions of java, multiple times, and the iterable ordering is always:
            3
            2
            1
            0
            7
            6
            5
            4
            9
            8

            so, iterable ordering is not random. however, the reason for the ordering is hidden behind the Set interface, and so the specs for implementing Set :
            (1) chose any ordering
            (2) however, the ordering must be consistent.

            given this and my limited knowledge, i could never implement Set . if all i know is that i am going to be handed an instance of java.lang.Object , what could i grab onto to guarantee a consistent iterable ordering? well, this is hypothetical since i'm never going to implement Set .
            • 3. Re: why does ExecutorService.invokeAll() accept a Collection and return a List?
              3004
              kogose wrote:
              so, iterable ordering is not random.
              Nobody ever said it was.
              given this and my limited knowledge, i could never implement Set . if all i know is that i am going to be handed an instance of java.lang.Object , what could i grab onto to guarantee a consistent iterable ordering?
              It depends on your implementation. But really, in most cases you'd have to go out of your way to not have it consistent. If you want to know how Java's Set implementations--HashSet, LinkedHashSet, and TreeSet do it, look at their source code in src.zip.