java - How to Iteratre over Future<List> Object? -

the return value of call() method list<person>. mycallable class looks this:

public class mycallable implements callable <list<person>>{      public list<person> call() throws exception {            ...              return list     }      public mycallable(list<account> accountlist) {         super();     } } 

below code im writing in callablefuture class

    executorservice executor = executors.newfixedthreadpool(nthreds);                 list<future<list<person>>> list = new arraylist<future<list<person>>>();                 (int = 0; < 20; i++) {                         callable<list<person>> worker = new mycallable(accountlist);                         future<list<person>> submit = executor.submit(worker);                         for(future<list<person>> :list){                             //list.add(submit);                         }                 } 

i don't know how iterate on list , add submit it. doing right?

couple of problems. first of all, rather attempting grab results of future after submitting each 1 (if you're serializing , defeating purpose), submit all of them, , then retrieve results:

list<future<list<person>>> list = new arraylist<future<list<person>>>(); (int = 0; < 20; i++) {     callable<list<person>> worker = new mycallable(accountlist);     future<list<person>> submit = executor.submit(worker);     list.add(submit); // keep track of them }  // next step results... 

next, you're having basic syntax problems. in general iterate on items in container syntax is:

list<a> list = ...;  (a : list) {    // things 'a' } 

and finally, need check docs future, show how wait computed , obtain results using future#get().

putting end next step (after submitting above) being:

// ... tasks submitted , 'list' contains futures, next step:  (future<list<person>> future : list) {     list<person> result = future.get(); // wait task complete     // 'result' list<person> returned corresponding callable. } 

the idea behind submitting then getting results allow tasks execute concurrently instead of waiting each 1 complete before adding next. then, @ end, if end waiting on few, it's ok, because total wait time tasks has been reduced intended.