private String downloadSite(final String site) {
    try {
        log.debug("Downloading {}", site);
        final String res = IOUtils.toString(new URL("http://" + site), UTF_8);
        log.debug("Done {}", site);
        return res;
    } catch (IOException e) {
        throw Throwables.propagate(e);
    }
}

private Document parse(String xml)  //...

private CompletableFuture<Double> calculateRelevance(Document doc) //...

ExecutorService executor = Executors.newFixedThreadPool(4);

List<String> topSites = Arrays.asList(
        "www.google.com", "www.youtube.com", "www.yahoo.com", "www.msn.com"
);

List<CompletableFuture<Double>> relevanceFutures = topSites.stream().
        map(site -> CompletableFuture.supplyAsync(() -> downloadSite(site), executor)).
        map(contentFuture -> contentFuture.thenApply(this::parse)).
        map(docFuture -> docFuture.thenCompose(this::calculateRelevance)).
        collect(Collectors.<CompletableFuture<Double>>toList());

private static <T> CompletableFuture<List<T>> sequence(List<CompletableFuture<T>> futures) {
    CompletableFuture<Void> allDoneFuture =
        CompletableFuture.allOf(futures.toArray(new CompletableFuture[futures.size()]));
    return allDoneFuture.thenApply(v ->
            futures.stream().
                    map(future -> future.join()).
                    collect(Collectors.<T>toList())
    );
}

CompletableFuture<List<Double>> allDone = sequence(relevanceFutures);
CompletableFuture<OptionalDouble> maxRelevance = allDone.thenApply(relevances ->
        relevances.stream().
                mapToDouble(Double::valueOf).
                max()
);

Shortcomings

• CompletableFuture.allOf() returning CompletableFuture<Void> discussed earlier. I think it's fair to say that if I pass a collection of futures and want to wait for all of them, I would also like to extract the results when they arrive easily. It's even worse with CompletableFuture.anyOf(). If I am waiting for any of the futures to complete, I can't imagine passing futures of different types, say CompletableFuture<Car> and CompletableFuture<Restaurant>. If I don't care which one completes first, how am I suppose to handle return type? Typically you will pass a collection of homogeneous futures (e.g. CompletableFuture<Car>) and then anyOf() can simply return future of that type (instead of CompletableFuture<Void> again).
  
  
• Mixing settable and listenable abstractions. In Guava there is ListenableFuture and SettableFuture extending it. ListenableFuture allows registering callbacks while SettableFuture adds possibility to set value of the future (resolve it) from arbitrary thread and context. CompletableFuture is equivalent to SettableFuture but there is no limited version equivalent to ListenableFuture. Why is it a problem? If API returns CompletableFuture and then two threads wait for it to complete (nothing wrong with that), one of these threads can resolve this future and wake up other thread, while it's only the API implementation that should do it. But when API tries to resolve the future later, call to complete() is ignored. It can lead to really nasty bugs which are avoided in Guava by separating these two responsibilities.
  
  
• CompletableFuture is ignored in JDK. ExecutorService was not retrofitted to return CompletableFuture. Literally CompletableFuture is not referenced anywhere in JDK. It's a really useful class, backward compatible with Future, but not really promoted in standard library.
  
  
• Bloated API (?) Fifty methods in total, most in three variants. Splitting settable and listenable (see above) would help. Also some methods like runAfterBoth() or runAfterEither() IMHO do not really belong to any CompletableFuture. Is there a difference between fast.runAfterBoth(predictable, ...) and predictable.runAfterBoth(fast, ...)? No, but API favours one or the other. Actually I believe runAfterBoth(fast, predictable, ...) much better expresses my intention.
  
  
• CompletableFuture.getNow(T) should take Supplier<T> instead of raw reference. In the example below expensiveAlternative() is always code, irrespective to whether future finished or not:
  
  

  future.getNow(expensiveAlternative());
  

  However we can easily tweak this behaviour (I know, there is a small race condition here, but the original getNow() works this way as well):
  
  

  public static <T> T getNow(
              CompletableFuture<T> future, 
              Supplier<T> valueIfAbsent) throws ExecutionException, InterruptedException {
      if (future.isDone()) {
          return future.get();
      } else {
          return valueIfAbsent.get();
      }
  }
  

  With this utility method we can avoid calling expensiveAlternative() when it's not needed:
  
  

  getNow(future, () -> expensiveAlternative());
  //or:
  getNow(future, this::expensiveAlternative);