Why There's No Future in Java Futures

This session examines how Java Future affects the design and implementation of highly concurrent multithreaded systems. It explains how, although being designed to facilitate concurrent programming, they often have the opposite effect, unnecessarily causing developers to burn threads and actually encouraging the development of blocking synchronous systems. It proposes several simple alternatives, including the notion of Deferreds and Collectors, together with a DSL-style framework for testing such implementations.

Copyright © 2013 Oracle and/or its affiliates. Oracle® is a registered trademark of Oracle and/or its affiliates. All rights reserved. Oracle disclaims any warranties or representations as to the accuracy or completeness of this recording, demonstration, and/or written materials (the "Materials"). The Materials are provided "as is" without any warranty of any kind, either express or implied, including without limitation warranties of merchantability, fitness for a particular purpose, and non-infringement.

[JakobJenkov]

A great presentation about implementing asynchronous code in Java. You need a little background info to understand what they are talking about, but not too much. I got some new ideas.

[brianoliver]

Not to offend anyone, but we've repetitively shown through extensive research that the use of Collectors is significantly more efficient on modern day CPUs and infrastructure than that of regular Java Futures (for the types of challenges we're trying to solve).

Futures are still powerful and useful, but for our use-cases, a 10x performance improvement using Collectors can't be ignored.

[tochistube]

The Future class is an implementation of ACT as specified in seminal POSA 2 text book by Doug Schmidt etc.

According to POSA 2, The Asynchronous Completion Token design pattern allows an application to demultiplex and process efficiently the responses of asynchronous operations it invokes on services.

I am struggling to see the point of this presentation which seems to be barking up the wrong tree. The solution to the supposed flaw of the Future class is certainly not new e.g. SwingWorker

[topicoish]

In the java API (6 and 7) ExecutorService doesn´t have a submit(Callable<T>, Object) method. This feature is for the new Java API (8). otherwise, how can I implement it?