[concurrency-interest] CompletableFuture in Java 8

√iktor Ҡlang viktor.klang at gmail.com
Tue Dec 9 05:05:08 EST 2014

On Mon, Dec 8, 2014 at 5:35 PM, Josh Humphries <jh at squareup.com> wrote:

> But CompletableFuture is a class, not an interface. So if the
>>> CompletionStage is not a CompletableFuture, you're still back to having to
>>> wrap the CompletionStage. You've just moved the responsibility out of
>>> CompletableFuture and into every other implementation of CompletionStage,
>>> which seems like an unusual choice.
>> Unusual: yes, unheard of: no. :) that is the same for
>> java.util.Collection which has a toArray (Collection is an interface, Array
>> is highly concrete). To be clear, I concede that it is suboptimal and if I
>> could go without I'd prefer not to have it!
> Right, Doug pointed out the same. But for the purpose of inter-op, Future
> (instead of CompletableFuture) would have sufficed.

True, but the difference is that if you throw away the stage after you get
`toFuture` your options are: downcasting to CompletionStage (if possible)
or blocking. Not a great tradeoff, right?

> BTW, Doug, I saw your other reply. I'm not suggesting that anything needs
> be done about the API. I was just listing some of my nits after Yu Lin
> asked about API differences between Guava's ListenableFuture and Java 8's
> CompletableFuture. I concede that my complaints are largely cosmetic -- the
> API doesn't prevent me from doing what I need to.
> You've already mentioned that you'd like to see ExecutorService retired.
>>> It definitely has plenty of sharp corners. But I'll hold judgement on
>>> whether or not its use should be retired for when I see its replacement
>>> (sorry, FJP, you're not it.)
>> I've pitched the idea to Doug that I'd love to see a FJP implementation
>> without the FJ, please chime in :)
> Yeah, that sounds nice, but I'd really have to hear and see more to have a
> strong opinion.

Collecting requirements would be a great start :)

> I'm actually toying with something that might be kinda-sorta like this
> now. It's like an ExecutorService, but you give each submission a "key"
> (think Actor or Listener) so submissions from outside of the pool (like
> non-FJ code) can try to pin the task to "the right thread" instead of a
> random thread (and hopefully get better L1 cache hit rate). At the same
> time, it also employs work-stealing to improve throughput and fairness.

I guess this is another of these things were application-level CPU
scheduling would be beneficial, since thread-pinning to core isn't

> One difference in what I'm trying to do is that it is specifically for
> sequential delivery of events to listeners (and could be used for executing
> operations on behalf of an actor in something like Akka). So its
> implementation is quite different from FJP since each "actor" has a
> separate queue. So each worker thread can have multiple queues (one per
> actor pinned to that worker) instead of a single work queue.

What we do in Akka is that we have a Runnable mailbox for each actor, so
that keeps contention down on the pool.

> I suspect there might be something something similar in Akka or Play (I'm
> just guessing -- I have only a passing familiarity with these frameworks).
> I'm suddenly kind of curious what folks on this list think of it:
> https://code.google.com/p/bluegosling/source/browse/src/com/apriori/concurrent/ActorThreadPool.java
That's going to take a while to digest :)

> RoR is a great example. Many companies today probably wouldn't exist if it
>>> weren't for RoR. Many have had to undergo major architectural change to
>>> later achieve those three things (performance, scalability, and
>>> maintainability). But for plenty (including Square), it was absolutely the
>>> right decision in order to get a product out quickly and at low cost. That
>>> velocity, even if it means future technical pain, can be critical for a
>>> young business in order to get early feedback and validate their business
>>> model as well as start generating revenue.
>> Absolutely. But I want to build technology that scales, so that one does
>> not have to rebuild once successful, and one can become successful quickly.
>> :)
> A virtuous objective indeed! And I think the Play framework is pretty
> attractive for this, although (I must confess) I haven't really used it,
> only looked into a little.
> For now, RoR seem to be more attractive to many largely, I think, due to
> Java's reputation (a lot of it due to language's verbosity vs. terseness
> for many idioms, some due its static typing and compile phase which slows
> down iteration [at least it is perceived to slow it down]).
> Scala has a bit of an advantage here over Java in that it doesn't have the
> same reputation scars -- at least that's the impression I get from Rubyists
> :)
> But I really hope Java 8 can recover some of that reputation. (It
> certainly deserves to!)

I think the main challenge for Java is that it is statement oriented rather
than expression oriented, means that there's a lot of mutation and
verboseness. I'm not sure that's fixable. Would be interesting to see
whether Java gets local type inference or not!

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20141209/1b4f843a/attachment-0001.html>

More information about the Concurrency-interest mailing list