[concurrency-interest] Re: 'Future' definition

Doug Lea dl@cs.oswego.edu
Mon, 9 Dec 2002 19:31:40 -0500

Patrick wrote:
> The Future interface needs to have a 'clear()' method as well as the
> 'set(Object)' and setException(Throwable)'

Note first that Set and setException are not in the Future
interface. They are declared as protected methods in the concrete
FutureTask class, so you need not expose them to users of Futures, but
only to the components that do the setting.

We also considered a clear/reset method, and rejected it.  Supporting
a reset method entails some extra complexity and policy decisions that
aren't wanted in the vast majority of uses. And in fact, different uses we
can think of are a little different about how it should work. For example,
is it OK to reset if/only-if/unless the previous value was obtained?

Given that Future is an interface, you can make your own
ResettableFuture and it will work fine with the rest of the
Executor/Future framework.

> As a final point, setException() should really be called setThrowable() in
> keeping with it's argument.

Thanks for the suggestion! 

(This means: I think setException sounds better, but maybe consistency
is better than connotation. We'll think about it.)