[concurrency-interest] CompletableFuture in Java 8

Josh Humphries jh at squareup.com
Mon Dec 8 11:35:10 EST 2014

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

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.

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.

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.

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:

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!)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20141208/3fe86460/attachment-0001.html>

More information about the Concurrency-interest mailing list