When to Use Callable and Supplier in Java

1. Overview

In this tutorial, we’ll discuss the Callable and Supplier functional interfaces, which are similar in structure but different in use.

Both return a typed value and don’t take any argument. The execution context is the discriminant that determines the differences.

In this tutorial, we’ll focus on the context of asynchronous tasks.

2. Model

Before we begin, let’s define a class:

public class User {

    private String name;
    private String surname;
    private LocalDate birthDate;
    private Integer age;
    private Boolean canDriveACar = false;

    // standard constructors, getters and setters
}

3. Callable

Callable is an interface introduced in version 5 of Java and evolved as a functional interface in version 8.

Its SAM (Single Abstract Method) is the method call() that returns a generic value and may throw an exception:

V call() throws Exception;

It’s designed to encapsulate a task that should be executed by another thread, such as the Runnable interface. That’s because Callable instances can be executed via ExecutorService.

So let’s define an implementation:

public class AgeCalculatorCallable implements Callable<Integer> {

    private final LocalDate birthDate;

    @Override
    public Integer call() throws Exception {
        return Period.between(birthDate, LocalDate.now()).getYears();
    }

    // standard constructors, getters and setters
}

When the call() method returns a value, the main thread retrieves it to do its logic. For this, we can use Future, an object that tracks and obtains the value upon completion of a task executed on another thread.

3.1. Single Task

Let’s define a method that executes only one asynchronous task:

public User execute(User user) {
    ExecutorService executorService = Executors.newCachedThreadPool();
    try {
        Future<Integer> ageFuture = executorService.submit(new AgeCalculatorCallable(user.getBirthDate()));
        user.setAge(ageFuture.get());
    } catch (ExecutionException | InterruptedException e) {
        throw new RuntimeException(e.getCause());
    }
    return user;
}

We can rewrite the internal block of the submit() via lambda expression:

Future<Integer> ageFuture = executorService.submit(
  () -> Period.between(user.getBirthDate(), LocalDate.now()).getYears());

When we try to access the return value by invoking the get() method, we have to handle two checked exceptions:

• InterruptedException: thrown when an interruption occurred while the thread is sleeping, active, or occupied
• ExecutionException: thrown when a task is aborted by throwing an exception. In other words, it’s a wrapper exception, and the real exception that aborted the task is the cause (and it can be inspected using the getCause() method).

3.2. Chain of Tasks

Executing a task belonging to a chain depends on the state of the previous tasks. If one of these fails, the current task can’t be executed.

So let’s define a new Callable:

public class CarDriverValidatorCallable implements Callable<Boolean> {

    private final Integer age;

    @Override
    public Boolean call() throws Exception {
        return age > 18;
    }
    // standard constructors, getters and setters
}

Next, let’s define a chain of tasks where the second task has the result of the previous task as an input parameter:

public User execute(User user) {
    ExecutorService executorService = Executors.newCachedThreadPool();
    try {
        Future<Integer> ageFuture = executorService.submit(new AgeCalculatorCallable(user.getBirthDate()));
        Integer age = ageFuture.get();
        Future<Boolean> canDriveACarFuture = executorService.submit(new CarDriverValidatorCallable(age));
        Boolean canDriveACar = canDriveACarFuture.get();
        user.setAge(age);
        user.setCanDriveACar(canDriveACar);
    } catch (ExecutionException | InterruptedException e) {
        throw new RuntimeException(e.getCause());
    }
    return user;
}

Using Callable and Future in a chain of tasks has some problems:

• Each task in the chain follows the pattern “submit-get”. In a long chain, this produces verbose code.
• When the chain is tolerant to a task failure, we should create a dedicated try/catch block.
• When invoked, the get() method waits until the Callable returns a value. So the total execution time of the chain equals the sum of the execution time of all the tasks. But if the next task depends on the correct execution of only one previous task, the chain process is significantly slowed down.

4. Supplier

Supplier is a functional interface whose SAM (Single Abstract Method) is get().

It doesn’t take any argument, returns a value, and throws only unchecked exceptions:

T get();

One of the most frequent use cases of this interface is to defer the execution of some code.

The Optional class has a few methods that accept a Supplier as a parameter, such as Optional.or(), Optional.orElseGet().

So the Supplier is executed only when the Optional is empty.

We can also use it in an asynchronous computation context, specifically in the CompletableFuture API.

Some methods accept a Supplier as a parameter, such as the supplyAsync() method.

4.1. Single Task

Let’s define a method that executes only one asynchronous task:

public User execute(User user) {
    ExecutorService executorService = Executors.newCachedThreadPool();
    CompletableFuture<Integer> ageFut = CompletableFuture.supplyAsync(() -> Period.between(user.getBirthDate(), LocalDate.now())
      .getYears(), executorService)
      .exceptionally(throwable -> {throw new RuntimeException(throwable);});
    user.setAge(ageFut.join());
    return user;
}

In this case, a lambda expression defines the Supplier, but we may also define an implementation class. Thanks to the CompletableFuture, we have defined a template for the asynchronous operation, making it simpler to understand and easier to modify.

The join() method provides the return value of the Supplier.

4.2. Chain of Tasks

We can also develop a chain of tasks with the support of the Supplier interface and CompletableFuture:

public User execute(User user) {
    ExecutorService executorService = Executors.newCachedThreadPool();
    CompletableFuture<Integer> ageFut = CompletableFuture.supplyAsync(() -> Period.between(user.getBirthDate(), LocalDate.now())
      .getYears(), executorService);
    CompletableFuture<Boolean> canDriveACarFut = ageFut.thenComposeAsync(age -> CompletableFuture.supplyAsync(() -> age > 18, executorService))
      .exceptionally((ex) -> false);
    user.setAge(ageFut.join());
    user.setCanDriveACar(canDriveACarFut.join());
    return user;
}

Defining a chain of asynchronous tasks with the CompletableFuture–Supplier approach may solve some problems introduced before with the Future–Callable approach:

• Each task of the chain is isolated. So if the execution of a task fails, we can handle it via the exceptionally() block.
• join() method doesn’t need to handle checked exceptions at compile time.
• We can design an asynchronous task template, improving the status handling of each task.

5. Conclusion

In this article, we discussed the differences between Callable and Supplier interfaces, focusing on the context of asynchronous tasks.

The main difference at the interface design level is the checked exception thrown by the Callable. 

Callable was not meant for a functional context. It was adapted over time, and functional programming and checked exceptions don’t get along.

So any functional API (such as CompletableFuture API) always accepts Supplier rather than Callable.