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 CompletableFutures to resolve as many Startables 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.