Listenablefuture vs Completablefuture

Question

J'ai essayé mais je n'ai pas trouvé d'article ou de blog qui compare clairement ListenableFuture et CompletableFuture et fournit une bonne analyse.

Donc si quelqu'un peut m'expliquer ou m'indiquer un tel blog ou article, ce sera vraiment bien pour moi.

Answer 1

ListenableFuture et CompletableFuture ont tous deux un avantage par rapport à leur classe parente Future en permettant à l'appelant d'"enregistrer" d'une manière ou d'une autre un callback à appeler lorsque l'action asynchrone est terminée.

Avec Futur vous pouvez le faire :

ExecutorService executor = ...;
Future f = executor.submit(...);
f.get();

f.get() se bloque jusqu'à ce que l'action asynchrone soit terminée ;

Avec EcoutableFutur vous pouvez enregistrer un callback comme ceci :

ListenableFuture listenable = service.submit(...);
    Futures.addCallback(listenable, new FutureCallback<Object>() {
                @Override
                public void onSuccess(Object o) {
                    //handle on success
                }

                @Override
                public void onFailure(Throwable throwable) {
                   //handle on failure
                }
            })

Avec CompletableFuture vous pouvez également enregistrer un callback lorsque la tâche est terminée, mais elle est différente de ListenableFuture en ce sens qu'elle peut être terminée à partir de n'importe quel thread qui le souhaite.

CompletableFuture completableFuture = new CompletableFuture();
    completableFuture.whenComplete(new BiConsumer() {
        @Override
        public void accept(Object o, Object o2) {
            //handle complete
        }
    }); // complete the task
    completableFuture.complete(new Object())

Lorsqu'un thread appelle complete sur la tâche, la valeur reçue d'un appel à get() est définie avec la valeur du paramètre si la tâche n'est pas déjà terminée.

Lisez sur CompletableFuture

Answer 2

L'AbstractFuture de Guava a ses limites :

1. L'écouteur est une liste, mais il n'est généralement utilisé qu'une seule fois - ce qui est excessif. Si plusieurs listeners sont nécessaires, il faut les gérer dans l'étape suivante, ou penser à la messagerie.

2. setException définit la valeur de retour comme Exception, donc l'utilisateur doit utiliser instanceof pour différencier Exception ou pas à get() comme l'a fait guava AbstractFuture.

3. Dans le pipeline Future, trop de couches addListener() rendre le code difficile à lire.

Je préfère CompletableFuture.supply().thenApply().thenAccept().handle()