[concurrency-interest] CompletableFuture in Java 8
viktor.klang at gmail.com
Wed Dec 3 09:21:45 EST 2014
On Wed, Dec 3, 2014 at 3:07 PM, Doug Lea <dl at cs.oswego.edu> wrote:
> On 12/01/2014 10:58 AM, √iktor Ҡlang wrote:
> I guess it depends whether one wants that feature overridable (one can go
>> CompletionStage to CompletableFuture with the combinators)
> Right. While overriding toCompletableFuture allows CompletionStage
> authors to disable direct conversion, it doesn't prevent their
> CompletionStage users from finding less efficient ways of
> performing blocking joins in particular. For example:
> CountdownLatch latch = ...;
> CompletableFuture cf = ....thenRun(() -> latch.countDown());
> Which leads me to re-wonder why any CompletionStage implementor
> would ever bother to disable.
Default impl would just create a -new- CompletableFuture and
CompletableFuture would override to return this?
> Digressing: I noticed while googling around for such constructions
> that people sometimes use them to ensure that their main()
> program using default-ayncs doesn't exit before computation
> is complete. It would be better to use
> ForkJoinPool.commonPool().awaitQuiescence(timeout, unit).
> But this method has timeout arguments that people
> probably don't want to think about in this case.
> And the need for it is non-obvious to new users.
> We should consider doing something about this.
I'm working on some hobby-research in how to supersede hardcoded timeouts.
> But we can/do add new better stuff that we encourage people to use
>> instead of old stuff when it becomes less useful as the world changes.
>> Hmmm, if only there was some kind of successor-like language to Java...
> Although any such language that specifically disallowed access to
> JDK classes that you don't happen to like might not fare so well :-)
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest