The generic return type of result-less futures
Chris Vest via Concurrency-interest <[email protected]> Mon, 6 Sep 2021 10:25:37 +0200
| Newsgroups | gmane.comp.java.jsr.166-concurrency |
|---|---|
| Message-ID | <CAHXi_0fjeT5ofe879MMrqFth=xHoVZtm+zsZT36U1Gq=VMgJ9w@mail.gmail.com> |
Hi, I looked through the mailing list archives, but I didn't see any previous discussion of this. Since Runnables don't return anything, there could be a question of what the generic type of the future should be. It looks like it has been a wildcard from the beginning: http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/java/util/concurrent/ExecutorService.java?r1=1.7&r2=1.8#l29 although it was removed at one point: http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/java/util/concurrent/ExecutorService.java?r1=1.13&r2=1.14#l33 but later returned: http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/java/util/concurrent/ExecutorService.java?r1=1.17&r2=1.18#l129 and in that process changed from producing a future that returns "an arbitrary value" to "return null". So since it then returns null, the future could - as far as I can tell - just as well be typed to return Object or Void. I'm wondering if there are any specific reasons in favour of wildcards, or against Object or Void, that I'm not seeing. Thanks, Chris