Everyone praises Executor framework (that one in java.util.concurrent). But I'm stucked with such a problem.
I want to execute different tasks in thread pool and don't want to wait for their results in get method of Future interface. I just want some things to be done immediately after the execution completes (either with return or with exception). The only thing I was able to find to implement such listening for task completion is protected method of ThreadPoolExecutor class - afterExecute. This brings two unpleasant things: extending executor and messing with afterExecute parameters (Runnable, Throwable).
I wonder why the creators of Executor framework couldn't just provide the setter for listener interface in order to pass him the results (something like Future) upon task completion? Am I missing something? Why choosing between synchronous get and unhandy afterExecute?
Can you advise any technique to solve my problem? It seems to be so trivial, just returning results upon completion. That is why I can't believe the framework is not suitable for such scenario.
You may extend the FutureTask class and imlement your own done() method.
This method is called just after the task is completed.
Maybe like this:
Joined: Sep 07, 2009
Thank you, Ireneusz! I can't believe this happens to me!
Strange things a have found only one example of using done() while googling. The other examples are plain get() calling. Why does everybody like hanging thread while waiting for result?
Nevertheless I've just successfully implemented my scenario. I extended FutureTask class in such a way:
Everything is easy and understandable now. So, thank you again, Ireneusz!