[concurrency-interest] Re: 'Future' definition

Patrick Moore pmoore@brocade.com
Tue, 10 Dec 2002 10:25:02 -0800


This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C2A079.7478DC80
Content-Type: text/plain

Hi Doug -

The decision about not having a clear() method in the Future interface would
be more tolerable if it wasn't for the fact that such a method is missing
(even protected) from FutureTask. Since set(null) is not the same as a
clear(), this means that I have to:

1) reimplement all of FutureTask's functionality or
2) using reflection trickery ( Method/Field.setAccessable(true) ) in a
FutureTask subclass or 
3) Continue to use the EDU version...

I would suggest that if it is perfectly permissible and useful to have the
set(), setThrowable(), clear() methods in the interface but define it that
implementors of the interface may throw UnsupportedOperationException.
(There are plenty of examples of this in the Collections as well as Iterator
does the same.) So FutureTask may have:

protected void _set(Object o){
...}
public void set(Object) {
   throw new UnsupportedOperationException();
}
protected void _setThrowable(Throwable t) {
...
}
public void setThrowable(Throwable t) {
   throw new UnsupportedOperationException();
}
protected void _clear() {
...
}
public void clear() {
   throw new UnsupportedOperationException();
}

-----Original Message-----
From: Doug Lea [mailto:dl@cs.oswego.edu]
Sent: Monday, December 09, 2002 4:32 PM
To: concurrency-interest@altair.cs.oswego.edu
Subject: [concurrency-interest] Re: 'Future' definition



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.)

-Doug

_______________________________________________
Concurrency-interest mailing list
Concurrency-interest@altair.cs.oswego.edu
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest

------_=_NextPart_001_01C2A079.7478DC80
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: [concurrency-interest] Re: 'Future' definition</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Hi Doug -</FONT>
</P>

<P><FONT SIZE=3D2>The decision about not having a clear() method in the =
Future interface would be more tolerable if it wasn't for the fact that =
such a method is missing (even protected) from FutureTask. Since =
set(null) is not the same as a clear(), this means that I have =
to:</FONT></P>

<P><FONT SIZE=3D2>1) reimplement all of FutureTask's functionality =
or</FONT>
<BR><FONT SIZE=3D2>2) using reflection trickery ( =
Method/Field.setAccessable(true) ) in a FutureTask subclass or </FONT>
<BR><FONT SIZE=3D2>3) Continue to use the EDU version...</FONT>
</P>

<P><FONT SIZE=3D2>I would suggest that if it is perfectly permissible =
and useful to have the set(), setThrowable(), clear() methods in the =
interface but define it that implementors of the interface may throw =
UnsupportedOperationException. (There are plenty of examples of this in =
the Collections as well as Iterator does the same.) So FutureTask may =
have:</FONT></P>

<P><FONT SIZE=3D2>protected void _set(Object o){</FONT>
<BR><FONT SIZE=3D2>...}</FONT>
<BR><FONT SIZE=3D2>public void set(Object) {</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; throw new =
UnsupportedOperationException();</FONT>
<BR><FONT SIZE=3D2>}</FONT>
<BR><FONT SIZE=3D2>protected void _setThrowable(Throwable t) {</FONT>
<BR><FONT SIZE=3D2>...</FONT>
<BR><FONT SIZE=3D2>}</FONT>
<BR><FONT SIZE=3D2>public void setThrowable(Throwable t) {</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; throw new =
UnsupportedOperationException();</FONT>
<BR><FONT SIZE=3D2>}</FONT>
<BR><FONT SIZE=3D2>protected void _clear() {</FONT>
<BR><FONT SIZE=3D2>...</FONT>
<BR><FONT SIZE=3D2>}</FONT>
<BR><FONT SIZE=3D2>public void clear() {</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; throw new =
UnsupportedOperationException();</FONT>
<BR><FONT SIZE=3D2>}</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Doug Lea [<A =
HREF=3D"mailto:dl@cs.oswego.edu">mailto:dl@cs.oswego.edu</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Monday, December 09, 2002 4:32 PM</FONT>
<BR><FONT SIZE=3D2>To: concurrency-interest@altair.cs.oswego.edu</FONT>
<BR><FONT SIZE=3D2>Subject: [concurrency-interest] Re: 'Future' =
definition</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>Patrick wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; The Future interface needs to have a 'clear()' =
method as well as the</FONT>
<BR><FONT SIZE=3D2>&gt; 'set(Object)' and =
setException(Throwable)'</FONT>
</P>

<P><FONT SIZE=3D2>Note first that Set and setException are not in the =
Future</FONT>
<BR><FONT SIZE=3D2>interface. They are declared as protected methods in =
the concrete</FONT>
<BR><FONT SIZE=3D2>FutureTask class, so you need not expose them to =
users of Futures, but</FONT>
<BR><FONT SIZE=3D2>only to the components that do the setting.</FONT>
</P>

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

<P><FONT SIZE=3D2>Given that Future is an interface, you can make your =
own</FONT>
<BR><FONT SIZE=3D2>ResettableFuture and it will work fine with the rest =
of the</FONT>
<BR><FONT SIZE=3D2>Executor/Future framework.</FONT>
</P>

<P><FONT SIZE=3D2>&gt; As a final point, setException() should really =
be called setThrowable() in</FONT>
<BR><FONT SIZE=3D2>&gt; keeping with it's argument.</FONT>
</P>

<P><FONT SIZE=3D2>Thanks for the suggestion! </FONT>
</P>

<P><FONT SIZE=3D2>(This means: I think setException sounds better, but =
maybe consistency</FONT>
<BR><FONT SIZE=3D2>is better than connotation. We'll think about =
it.)</FONT>
</P>

<P><FONT SIZE=3D2>-Doug</FONT>
</P>

<P><FONT =
SIZE=3D2>_______________________________________________</FONT>
<BR><FONT SIZE=3D2>Concurrency-interest mailing list</FONT>
<BR><FONT SIZE=3D2>Concurrency-interest@altair.cs.oswego.edu</FONT>
<BR><FONT SIZE=3D2><A =
HREF=3D"http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interes=
t" =
TARGET=3D"_blank">http://altair.cs.oswego.edu/mailman/listinfo/concurren=
cy-interest</A></FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C2A079.7478DC80--