public final class Startables
extends java.lang.Object
Modifier and Type | Method and Description |
---|---|
static java.util.concurrent.CompletableFuture<java.lang.Void> |
deepStart(java.util.Collection<? extends Startable> startables) |
static java.util.concurrent.CompletableFuture<java.lang.Void> |
deepStart(java.lang.Iterable<? extends Startable> startables) |
static java.util.concurrent.CompletableFuture<java.lang.Void> |
deepStart(Startable... startables) |
static java.util.concurrent.CompletableFuture<java.lang.Void> |
deepStart(java.util.stream.Stream<? extends Startable> startables)
Start every
Startable recursively and asynchronously and join on the result. |
public static java.util.concurrent.CompletableFuture<java.lang.Void> deepStart(java.util.Collection<? extends Startable> startables)
deepStart(Stream)
public static java.util.concurrent.CompletableFuture<java.lang.Void> deepStart(java.lang.Iterable<? extends Startable> startables)
deepStart(Stream)
public static java.util.concurrent.CompletableFuture<java.lang.Void> deepStart(Startable... startables)
deepStart(Stream)
public static java.util.concurrent.CompletableFuture<java.lang.Void> deepStart(java.util.stream.Stream<? extends Startable> startables)
Startable
recursively and asynchronously and join on the result.
Performance note:
The method uses and returns CompletableFuture
s to resolve as many Startable
s at once as possible.
This way, for the following graph:
/ b \
a e
c /
d /
"a", "c" and "d" will resolve in parallel, then "b".
If we would call blocking Startable.start()
, "e" would wait for "b", "b" for "a", and only then "c", and then "d".
But, since "c" and "d" are independent from "a", there is no point in waiting for "a" to be resolved first.