Multithreading:When and Why should you use CompletableFuture instead of Future in Java 8

Multithreading in Java 8:

In this video I'll cover the main difference between Future and CompletableFuture in Java 8

If you liked the video, you may want to consider the below course:

[nagapradeepvankayala]

This is the best explanation in a quick way in very less time by directly coming to the main points. Excellent!!! Thank you so much...

[Rajsanab]

So, nice. I like this kind of learning. Bcz if we learn any topic with real time example, we cannot forget it. Thanks .

[rmvinodh]

Very nicely explained! Thank you for sharing this content!

[kumarmanish]

But we can implement a callable in which we call the 3 one by one. We give each order to one thread so that way orders will run in parallel, right ? no need of completable future ?

[prashantjha]

Frameworks like completableFuture has paved the path for reactive programming but also made developers forget the threading part of the application, like how the callbacks are executed across different threads and which thread is really making the IO call in the case of completableFuture. And once the IO call finish how the OS is notified via interrupt and the registered callback is invoked.

[adikztv]

So it looks like there is no point in using plain Futures?

[sundarg]

Content is good, but voice is too low.. please take care next time

[nadaralpenidze]

Sorry, but that's a bad example, which doesn't compare apples to apples.
In your first example, you ran the exeuction of the code sequentially, not batching the 3 steps onto separate threads. So your bottleneck was waiting for EVERY operation to finish.
While, in your second example, you scheduled [order -> inventory -> pay] triplet on a separate thread, so all 9 ran simultaneously.

You could achieve the same performance with Futures if every iteration of the for loop was scheduled onto a separate thread. Only the 3 operations are sequential, but the 9 orders are unbound to each other.
Sorry, but that may give new engineers a completely wrong image.

The real benefit of completable futures is the chaining of operations, which you displayed. They happen sequentially, but you don't need to manage the thread joins, which allows for cleaner coding paradigms.

If you take it down to first principles, threads are threads, and if you need data from a concurrently executing thread, you need to wait for it to finish. The paradigm here is what changes.