Java Reference
In-Depth Information
What this means in the case of
Example 9-9
is that we can't start either of the calls to the
lookup services until we've logged into both of them. This is pretty unnecessary:
lookup-
Tracks
only needs its login credentials, and
lookupArtists
should only need to wait for its
login credentials. The breakdown of which actions need to wait for others to complete is
shown in
Figure 9-3
.
We could take the blocking
get
calls and drag them down into the execution body of
look-
upTracks
and
lookupArtists
. This would solve the problem, but would also result in uglier
code and an inability to reuse credentials between multiple calls.
Figure 9-3. Both lookup actions don't need to wait for both login actions
What we really want here is a way of acting on the result of a
Future
,
without
having to
make a blocking
get
call. We want to combine a
Future
with a callback.
Completable Futures
The solution to these issues arrives in the form of the
CompletableFuture
. This combines
the IOU idea of a
Future
with using callbacks to handle event-driven work. The key point
about the
CompletableFuture
is that you can compose different instances in a way that
doesn't result in the pyramid of doom.