[concurrency-interest] Re: 'Future' definition

Dawid Kurzyniec dawidk@mathcs.emory.edu
Tue, 10 Dec 2002 21:32:20 -0500

On Tuesday 10 December 2002 05:21 pm, Patrick Moore wrote:

> I don't find the discussion to which you refer in the concurrency archives.
> If this happened in the jsr mailing list please send a link as it isn't in
> the concurrency-interest archive.

Sorry, I should have been more specific. That thread started 10 Sep 2002; the 
name was: "Futures, callbacks, callables, runnables, and executors once 
again". Here is the URL to the first posting: 

> ...
> I don't see how being able to clear() is this huge barrier to being a first
> class object. If some code needs the value not to change during an
> operation it simply extracts the Future wrapped value. 

I was referring to the situation when you want to pass around the future 
object before it gets determined, i.e. without waiting for async operation to 

> With regards to the
> immutablity, you haven't explained why a mechanism, throwing
> UnsupportedOperationException, that is used elsewhere for exactly this kind
> of situation is inadequate here. 

The difference is that sets and maps are mutable by definition, and 
immutability is for special cases. On the other hand, future is immutable *by 
definition*. The concept is about 12 years old; the definitions I've found 
can be described as: "future is a const with deferred binding".

Now I believe that interfaces should clearly represent underlying 
abstractions. Having set() and reset() methods in the Future interface would 
obfuscate the abstraction, suggesting that there is a symmetry betwen get and 

> Call Future volatile if you must but the
> EDU package solves a real-world problem that this new package won't.

But it saves (me, for instance) from other real-world problems that the old 
package have been introducing (in fact, I was forced to use my own version of 
Future exactly to avoid those problems). Please check out the archived thread 
for much more details (e.g. point "4 iv" in my first posting).

> In response to your comment:
> "Why don't you instead write your own "result handler" or "cache object"
> with set and clear
> methods invoked by callbacks, without necessarily implementing the Future
> interface."
> My answer is why? What is the significant difference? What is the contact
> that I am violating? Why should I write my own when
> EDU.oswego.cs.dl.util.concurrent.FutureResult is perfectly correct and
> adequate. The Future concept works well and fits with the behavior.

Well, as I said - I don't think it is adequate if it is called "future", as it 
violates semantics of what people know and understand as a future. To me, it 
is analogous to trying to eat soup with fork, and complaining that it leaks. 
So there are no more non-leaking forks in the new API; there is no spoon 
either - you simply must bring your own spoon to the party. The EG admitted 
that in order to meet schedule they must sometimes have cut functionality for 
the first release. It means that spoon may arrive in forthcoming versions, 
but until it does, I think it is better to ask guests to bring their own 
spoons than offering them multi-purpose swiss-knife forks that can also play 
music, but for the price of making it difficult to stick them in the food.

> If you think that having an immutable Future(Result) is important - I will
> not disagree at all with you on that. The problem I have is that now I have
> *less* functionality than I did before - which I will strongly disagree
> about.
> Like I indicated... not having it in there leaves me 3 choices none of them
> very correct but each is 'better' than riting my own since I leverage
> existing code.

I see your point, but I don't agree that it is better in this case (to wrap a 
paper around the fork instead of making a brand-new spoon :). Let we face 
this like men: the code of FutureTask is very simple, you actually do not 
need all of it to implement your cache example, so the amount of code you 
need to write is about 30-40 lines, and most of it you can take directly from 
public-domain dl.u.c. On the other hand, if the facilities you postulate were 
there, I would likely be forced to create special adapters to hide setters 
and make things safe - then I would have to write that 30-40 lines. 

That's true that some functionality has been removed with this change, but I 
think that it makes the API more consistent and it simplifies things for far 
more people that are affected by the functionality loss.

Also, it seems that EG has already very strong opinion on this (since it was 
discussed long time ago, and also considering Doug's response) and I don't 
think they are likely to change it again.