There is no possibility to remove future callback

[GoogleCodeExporter]

Current implementation of 
com.google.common.util.concurrent.ListenableFutureTask doesn't provide method 
for removing FutureCallback added via 
com.google.common.util.concurrent.Futures#addCallback method.

Original issue reported on code.google.com by se.solov...@gmail.com on 8 Apr 2013 at 7:40

[GoogleCodeExporter]

Now that you mention it, I'm kind of shocked that this hadn't even occurred to 
me before. As far as I know, it's never come up. Under what circumstances do 
you want to remove listeners?

Original comment by cpov...@google.com on 8 Apr 2013 at 7:43

[GoogleCodeExporter]

Currently I'm working on a library which is mostly used in Android.
Here are the sources of the class which implements background task management 
(adding, running, cancelling and so on): 
https://github.com/serso/common/blob/master/tasks/src/main/java/org/solovyev/tas
ks/TaskServiceImpl.java
Usually, tasks which run in background do significant amount of work (e.g. they 
work for several seconds and even more). If tasks are run from Android UI (and 
the result of the task will update UI) I add FutureCallback in order to receive 
result. User can close-reopen app (or just rotate the phone - the main point 
that view is reconstructed) and I need to remove and reattach callbacks so the 
"current" view will receive the result (and not the closed one). I use 
WeakReference to prevent memory leaks of views but GC is not so fast and some 
references are still valid even after the views are destroyed, that's why I 
want to use 'remove' method - to be sure that callback will never be called for 
not active ("destroyed") view. 

I looked through the code and found that the problem point us in 
com.google.common.util.concurrent.Futures#addCallback method - here we wrap 
FutureCallback with Runnable and forget equals/hashCode methods. After Runnable 
is fixed one can add removeListener method in 
com.google.common.util.concurrent.ListenableFuture interface.

It's really strange that I am the first person who face the problem as it seems 
to be quite common operation on a long background tasks.

Thank you for your quick answer, hope it will be fixed.

Original comment by se.solov...@gmail.com on 8 Apr 2013 at 7:57

[GoogleCodeExporter]

I'd imagine the "traditional" way to address this issue is to move that logic 
into the callback itself somehow -- e.g. keep track of the callbacks yourself, 
and store a field in the callback tracking which view should receive its result.

I don't know how many people roll their own ListenableFuture implementation 
instead of extending one of Guava's, but wouldn't adding a method there break 
all those users?

Original comment by wasserman.louis on 8 Apr 2013 at 8:09

[GoogleCodeExporter]

This issue has been migrated to GitHub.

It can be found at https://github.com/google/guava/issues/<issue id>

Original comment by cgdecker@google.com on 1 Nov 2014 at 4:12

• Added labels: MigratedToGitHub

[GoogleCodeExporter]

Original comment by cgdecker@google.com on 1 Nov 2014 at 4:18

• Changed state: Migrated

[GoogleCodeExporter]

Original comment by cgdecker@google.com on 3 Nov 2014 at 9:08

• Added labels: Restrict-AddIssueComment-Commit