3

I googled on this , but still could not get a solid understanding. I could not find any particular example that uses FutureTask(Runnable runnable, V result) constructor

Java doc says

Future submit(Runnable task, T result)

Submits a Runnable task for execution and returns a Future representing that task. The Future's get method will return the given result upon successful completion.

Looking at this my understanding is upon task completion futureTask.get() it will send us back the given result object passed which has nothing to do with the "Runnable" job. This is kind of a signal that the "Runnable "job is completed.

Any concrete usecase or any real life example would be really helpful

Also in conjunction to Enno's answer how it is different from using isdone() possibly in a loop.
Edited Also why not wait notify?

Abhijit Mazumder
  • 8,641
  • 7
  • 36
  • 44
  • A pragmatic answer: When you have a `Runnable` and want a `FutureTask` or a `Future`, you can use these constructs (passing `null` as the result) to "convert" the runnable object into a future/futuretask – Marco13 Aug 14 '14 at 14:00

2 Answers2

2

For example, you could do something like this:

Future<Article> article = 
    executor.submit(new PayForArticle(article.articleId), article);

showFunnyVideo();
playAlittleGame();

// ...OK let's actually show the user the article

Article article = article.get();

// The above will block until the article is payed for
// And throws exceptions if it failed

Edit:

How it different from `while (!futureTask.isdone) //sleep for sometime// //when done show article//

This is probably a different question but you should never do that because sleeping/checking/sleeping is less efficient than just calling get, and IMO is much clearer what you are trying to do.

Enno Shioji
  • 26,542
  • 13
  • 70
  • 109
  • I considered that before and now edited the question. How it different from `while (!futureTask.isdone) //sleep for sometime// //when done show article// – Abhijit Mazumder Aug 14 '14 at 12:03
  • Agreed @EnnoShioji. But is this the primary intent for this? or you can think of any other usecase? I do not necessarily agree on the clear part :) at least for me it is confusing sending and receiving the same object named "result" which has nothing to do with the computation in that particular thread. Also why not wait notify ? – Abhijit Mazumder Aug 14 '14 at 12:31
  • @AbhijitMazumder: Re: wait/notify, that's essentially what it does internally. As for it being confusing, it's not really if you see it from the caller's POV. All the caller cares is that it gets what it needs after `get` returns. If this method is the easiest to package a Future, then it's fine to use it. The caller doesn't care what method was used to package it. – Enno Shioji Aug 14 '14 at 12:58
2

So, this is derived from a real-life use case, although it might not be representative of standard usage. Basically, I was adapting existing code that returned runnable.

LocalService manager = ...; // this is not thread safe
CompletionService exec = new ExecutorCompletionService( ... );
List<URL> work = ...;
for( URL url : work ) {
   // this is existing code returning Runnable
   Runnable task = createTaskFor(url);
   exec.submit(task, url);
}
// we will report the URLs in the order they complete
for( int i = 0; i < work.size(); i++) {
   URL completed = exec.take();
   // manager isn't thread safe, so all calls to it are on this thread
   manager.reportCompleted(completed);
} 

So there you go. I only used it that one time. It was useful in combination with the CompletionService, since that allows task production and task completion to be decoupled but still communcate.

Darren Gilroy
  • 2,071
  • 11
  • 6