Callable vs Supplier interface in java

Question

The Callable and Supplier functional interfaces in java.util.concurrent and java.util.function packages respectively have the following signature-

public interface Callable<V> {
    V call() throws Exception;
}

public interface Supplier<T> {
    T get();
}

Are there some specific use case where each one of them fit more than the other?

Seibert

Note that call throws an Exception while supplydoes not. (Compared to Supplier) – Avocation

@Sweeper I was looking to use a functional interface in which I can pass a value. Both seem to fit the use case. – Seibert

Answer 1

Their difference in usage can be seen from their respective documentation:

Callable:

A task that returns a result and may throw an exception. Implementors define a single method with no arguments called call.

The Callable interface is similar to Runnable, in that both are designed for classes whose instances are potentially executed by another thread.

Supplier:

Represents a supplier of results.

There is no requirement that a new or distinct result be returned each time the supplier is invoked.

This means that the caller of Callable.call expects an exception to be thrown and will handle the exception accordingly. This is useful for tasks like reading and writing to files, where many kinds of IOExceptions can be thrown. Callable is also designed to be run on another thread.

Supplier on the other hand, is very general. It just "supplies a value" and that's it.

So Callable is more specialised than Supplier. If you are not dealing with another thread or your task is very unlikely to throw an exception, Supplier is recommended.

Sedgewick

Answer 2

The ins and outs

For Runnable and Callable, they've been parts of the concurrent package since Java 6. It implies that both of them are ready to be submitted to an Executor and run asynchronously. Here Callable has a specific usage.

While for Runnable (0 in 0 out), Supplier(0 in 1 out), Consumer(1 in 0 out) and Function(1 in 1 out), they've been parts of the functional feature since Java 8. All of them are ready to be handled by something lambda friendly, like CompletableFuture. Here Supplier just means a function without any input param but has a return value, which is highly abstract.

	0 in (arguments)	1 in (argument)
0 out (returned)	Runnable	Consumer
1 out (returned)	Supplier	Function

Chokeberry

Your "in-out" analysis was enlightening for me. Thanks. I added a table to visualize that analysis. – Discounter

Answer 3

Apart from the obvious, Callable throwing an exception, the difference is semantic. They have different names because they represent different things. The purpose is to make code easier to understand. When you use a Callable, your interface choice implies that the object is going to be executed by another thread. When you use Supplier you imply that it's just an object that supplies data to another component.

Epilate

Apart from the naming semantics, is there anything at the implementation level which makes Callable a better choice in a multi threaded environment? Is it not safe to use Supplier in a multi threaded context? – Seibert

No difference. They are just interfaces. – Epilate

Answer 4

IMO, the primary difference between Callable and Supplier is whether you prefer the use of checked vs unchecked exceptions.

Earlier, the Java ecosystem used to prefer checked exceptions for every scenario which is expected to be encountered. But post java-8, checked exceptions have gone down in popular usage. (eg: ExecutionException vs CompletionException are both typically used to wrap exception during the execution of an async task but the former is checked and the latter isn't)

This is even seen in some libraries (Jacksons json parsing throws checked exception vs Gson throws unchecked etc).

It's not correct to say that if it's going to execute in another thread, use Callable. For example, CompletableFuture.supplyAsync(supplier) executes the supplier in another thread.

Barbi