Re: The generic return type of result-less futures
Kevin Bourrillion via Concurrency-interest <[email protected]> Tue, 14 Sep 2021 13:34:16 -0700
| Newsgroups | gmane.comp.java.jsr.166-concurrency |
|---|---|
| Message-ID | <CAGKkBks1kMDrWJ3ttLziyHX1YnTHc=ppeVPfRpG6vNAnu+guRg@mail.gmail.com> |
--===============8503360261280794819== Content-Type: multipart/alternative; boundary="0000000000005fbe2f05cbfa82f3" --0000000000005fbe2f05cbfa82f3 Content-Type: text/plain; charset="UTF-8" I'll add (as cpovirk's teammate) that it's been a useful general principle for us to never use wildcards in return types, probably not worth carving out a special case for. (I'm not sure why EJ3e (on p142) only speaks against *bounded* wildcards in return types.) On Tue, Sep 14, 2021 at 12:54 PM Chris Povirk via Concurrency-interest < [email protected]> wrote: > I was in no way involved in any of these decisions, but I happen to have > opinions from designing similar APIs in Guava, which may or may not be of > any interest here. > > First: It looks to me like the version of ExecutorService in which the > wildcard was "removed" was actually just the introduction of the new > `(Runnable, T)` overload, which naturally returns Future<T>? That is, I > think the wildcard-returning version has always been there? > > Second: It looks like newer JDK methods have chosen to return > Future<Void>. For example, see CompletableFuture.allOf > <https://docs.oracle.com/en/java/javase/16/docs/api/java.base/java/util/concurrent/CompletableFuture.html#allOf(java.util.concurrent.CompletableFuture...)> > . > > As for the actual considerations: There seems to be one main point in > favor of Future<?>: > > - "Future<?>" is shorter than "Future<Void>." It's also significantly > shorter than "Future<@Nullable Void>," which is what you'd have to write > when using some nullness checkers. > > Future<Void> has various advantages: > > - It explicitly declares "no useful return type" rather than "possibly > some useful return type, possibly not." > - Wildcards are confusing: We saw a surprising number of callers who > avoided submit(someRunnable) in favor of submit(someRunnable, null) just so > that they could have a non-wildcard Future. They seemed to find it easier > to reason about the types they'd need in their declarations when, e.g., > attaching a listener to the Future. > - Wildcards are confusing: They lead to longer error messages. > - Wildcards can cause type-inference problems: We've seen problems > calling methods like Guava's Futures.whenAllComplete > <https://guava.dev/releases/snapshot-jre/api/docs/com/google/common/util/concurrent/Futures.html#whenAllComplete(com.google.common.util.concurrent.ListenableFuture...)> > when passing Future instances whose value type is a wildcard. > - While an API probably shouldn't require a Future<Void> as an input, > if one does, then it's nice to have a Future<Void> available. (In contrast, > an API that accepts a Future<?> works with a Future<Void> and a Future<?> > equally well.) > > Putting that all together, we picked Void for our new methods (example > <https://guava.dev/releases/snapshot-jre/api/docs/com/google/common/util/concurrent/Futures.html#submit(java.lang.Runnable,java.util.concurrent.Executor)> > ). > _______________________________________________ > Concurrency-interest mailing list > [email protected] > http://cs.oswego.edu/mailman/listinfo/concurrency-interest > -- Kevin Bourrillion | Java Librarian | Google, Inc. | [email protected] --0000000000005fbe2f05cbfa82f3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">I'll add (as cpovirk's teammate) that it's bee= n a useful general principle for us to never use wildcards in return types,= probably not worth carving out a special case for.<div><br></div><div>(I&#= 39;m not sure why EJ3e (on p142) only speaks against <i>bounded</i>=C2=A0wi= ldcards in return types.)</div><div><br></div><div><br></div></div><br><div= class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, Sep 14= , 2021 at 12:54 PM Chris Povirk via Concurrency-interest <<a href=3D"mai= lto:[email protected]" target=3D"_blank">concurrency-inter= [email protected]</a>> wrote:<br></div><blockquote class=3D"gmail_quote"= style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);p= adding-left:1ex"><div dir=3D"ltr">I was in no way involved in any of these = decisions, but I happen to have opinions from designing similar APIs in Gua= va, which may or may not be of any interest here.<div><br></div><div>First:= It looks to me like the version of ExecutorService in which the wildcard w= as "removed" was actually just the introduction of the new `(Runn= able, T)` overload, which naturally returns Future<T>? That is, I thi= nk the wildcard-returning version has always been there?</div><div><br></di= v><div>Second: It looks like newer JDK methods have chosen to return Future= <Void>. For example, see <a href=3D"https://docs.oracle.com/en/java/j= avase/16/docs/api/java.base/java/util/concurrent/CompletableFuture.html#all= Of(java.util.concurrent.CompletableFuture...)" target=3D"_blank">Completabl= eFuture.allOf</a>.</div><div><br></div><div>As for the actual consideration= s: There seems to be one main point in favor of Future<?>:</div><div>= <ul><li>"Future<?>" is shorter than "Future<Void>= ;." It's also significantly shorter than "Future<@Nullable= Void>," which is what you'd have to write when using some null= ness checkers.</li></ul><div>Future<Void> has various advantages:</di= v></div><div><ul><li>It explicitly declares "no useful return type&quo= t; rather than "possibly some useful return type, possibly not."<= /li><li>Wildcards are confusing: We saw a surprising number of callers who = avoided submit(someRunnable) in favor of submit(someRunnable, null) just so= that they could have a non-wildcard Future. They seemed to find it easier = to reason about the types they'd need in their declarations when, e.g.,= attaching a listener to the Future.</li><li>Wildcards are confusing: They = lead to longer error messages.=C2=A0<br></li><li>Wildcards can cause type-i= nference problems: We've seen problems calling methods like Guava's= <a href=3D"https://guava.dev/releases/snapshot-jre/api/docs/com/google/com= mon/util/concurrent/Futures.html#whenAllComplete(com.google.common.util.con= current.ListenableFuture...)" target=3D"_blank">Futures.whenAllComplete</a>= when passing Future instances whose value type is a wildcard.</li><li>Whil= e an API probably shouldn't require a Future<Void> as an input, i= f one does, then it's nice to have a Future<Void> available. (In = contrast, an API that accepts a Future<?> works with a Future<Void= > and a Future<?> equally well.)</li></ul><div>Putting that all to= gether, we picked Void for our new methods (<a href=3D"https://guava.dev/re= leases/snapshot-jre/api/docs/com/google/common/util/concurrent/Futures.html= #submit(java.lang.Runnable,java.util.concurrent.Executor)" target=3D"_blank= ">example</a>).</div></div></div> _______________________________________________<br> Concurrency-interest mailing list<br> <a href=3D"mailto:[email protected]" target=3D"_blank">Con= [email protected]</a><br> <a href=3D"http://cs.oswego.edu/mailman/listinfo/concurrency-interest" rel= =3D"noreferrer" target=3D"_blank">http://cs.oswego.edu/mailman/listinfo/con= currency-interest</a><br> </blockquote></div><br clear=3D"all"><div><br></div>-- <br><div dir=3D"ltr"= ><div dir=3D"ltr"><div><div dir=3D"ltr"><div><div dir=3D"ltr"><div style=3D= "line-height:1.5em;padding-top:10px;margin-top:10px;color:rgb(85,85,85);fon= t-family:sans-serif"><span style=3D"border-width:2px 0px 0px;border-style:s= olid;border-color:rgb(213,15,37);padding-top:2px;margin-top:2px">Kevin Bour= rillion=C2=A0|</span><span style=3D"border-width:2px 0px 0px;border-style:s= olid;border-color:rgb(51,105,232);padding-top:2px;margin-top:2px">=C2=A0Jav= a Librarian |</span><span style=3D"border-width:2px 0px 0px;border-style:so= lid;border-color:rgb(0,153,57);padding-top:2px;margin-top:2px">=C2=A0Google= , Inc.=C2=A0|</span><span style=3D"border-width:2px 0px 0px;border-style:so= lid;border-color:rgb(238,178,17);padding-top:2px;margin-top:2px">=C2=A0<a h= ref=3D"mailto:[email protected]" target=3D"_blank">[email protected]</a></s= pan></div></div></div></div></div></div></div> --0000000000005fbe2f05cbfa82f3-- --===============8503360261280794819== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Concurrency-interest mailing list [email protected] http://cs.oswego.edu/mailman/listinfo/concurrency-interest --===============8503360261280794819==--