Java SE 8 for the Really Impatient (2014)

---

3.7. Parallelizing Operations

When expressing operations as functional interfaces, the caller gives up control over the processing details. As long as the operations are applied so that the correct result is achieved, the caller has nothing to complain about. In particular, the library can make use of concurrency. For example, in image processing we can split the image into multiple strips and process each strip separately.

Here is a simple way of carrying out an image transformation in parallel. This code operates on Color[][] arrays instead of Image objects because the JavaFX PixelWriter is not threadsafe.

public static Color[][] parallelTransform(Color[][] in, UnaryOperator<Color> f) {
int n = Runtime.getRuntime().availableProcessors();
int height = in.length;
int width = in[0].length;
Color[][] out = new Color[height][width];
try {
ExecutorService pool = Executors.newCachedThreadPool();
for (int i = 0; i < n; i++) {
int fromY = i * height / n;
int toY = (i + 1) * height / n;
pool.submit(() -> {
for (int x = 0; x < width; x++)
for (int y = fromY; y < toY; y++)
out[y][x] = f.apply(in[y][x]);
});
}
pool.shutdown();
pool.awaitTermination(1, TimeUnit.HOURS);
}
catch (InterruptedException ex) {
ex.printStackTrace();
}
return out;
}

This is, of course, just a proof of concept. Supporting image operations that combine multiple pixels would be a major challenge.

In general, when you are given an object of a functional interface and you need to invoke it many times, ask yourself whether you can take advantage of concurrency.

3.8. Dealing with Exceptions

When you write a method that accepts lambdas, you need to spend some thought on handling and reporting exceptions that may occur when the lambda expression is executed.

When an exception is thrown in a lambda expression, it is propagated to the caller. There is nothing special about executing lambda expressions, of course. They are simply method calls on some object that implements a functional interface. Often it is appropriate to let the expression bubble up to the caller.

Consider, for example:

public static void doInOrder(Runnable first, Runnable second) {
first.run();
second.run();
}

If first.run() throws an exception, then the doInOrder method is terminated, second is never run, and the caller gets to deal with the exception.

But now suppose we execute the tasks asynchronously.

public static void doInOrderAsync(Runnable first, Runnable second) {
Thread t = new Thread() {
public void run() {
first.run();
second.run();
}
};
t.start();
}

If first.run() throws an exception, the thread is terminated, and second is never run. However, the doInOrderAsync returns right away and does the work in a separate thread, so it is not possible to have the method rethrow the exception. In this situation, it is a good idea to supply a handler:

public static void doInOrderAsync(Runnable first, Runnable second,
Consumer<Throwable> handler) {
Thread t = new Thread() {
public void run() {
try {
first.run();
second.run();
} catch (Throwable t) {
handler.accept(t);
}
}
};
t.start();
}

Now suppose that first produces a result that is consumed by second. We can still use the handler.

public static <T> void doInOrderAsync(Supplier<T> first, Consumer<T> second,
Consumer<Throwable> handler) {
Thread t = new Thread() {
public void run() {
try {
T result = first.get();
second.accept(result);
} catch (Throwable t) {
handler.accept(t);
}
}
};
t.start();
}

Alternatively, we could make second a BiConsumer<T, Throwable> and have it deal with the exception from first—see Exercise 16.

It is often inconvenient that methods in functional interfaces don’t allow checked exceptions. Of course, your methods can accept functional interfaces whose methods allow checked exceptions, such as Callable<T> instead of Supplier<T>. A Callable<T> has a method that is declared as T call() throws Exception. If you want an equivalent for a Consumer or a Function, you have to create it yourself.

You sometimes see suggestions to “fix” this problem with a generic wrapper, like this:

public static <T> Supplier<T> unchecked(Callable<T> f) {
return () -> {
try {
return f.call();
}
catch (Exception e) {
throw new RuntimeException(e);
}
catch (Throwable t) {
throw t;
}
};
}

Then you can pass a

unchecked(() -> new String(Files.readAllBytes(
Paths.get("/etc/passwd")), StandardCharsets.UTF_8))

to a Supplier<String>, even though the readAllBytes method throws an IOException.

That is a solution, but not a complete fix. For example, this method cannot generate a Consumer<T> or a Function<T, U>. You would need to implement a variation of unchecked for each functional interface.

3.9. Lambdas and Generics

Generally, lambdas work well with generic types. You have seen a number of examples where we wrote generic mechanisms, such as the unchecked method of the preceding section. There are just a couple of issues to keep in mind.

One of the unhappy consequences of type erasure is that you cannot construct a generic array at runtime. For example, the toArray() method of Collection<T> and Stream<T> cannot call T[] result = new T[n]. Therefore, these methods return Object[] arrays. In the past, the solution was to provide a second method that accepts an array. That array was either filled or used to create a new one via reflection. For example, Collection<T> has a method toArray(T[] a). With lambdas, you have a new option, namely to pass the constructor. That is what you do with streams:

String[] result = words.toArray(String[]::new);

When you implement such a method, the constructor expression is an IntFunction<T[]>, since the size of the array is passed to the constructor. In your code, you call T[] result = constr.apply(n).

In this regard, lambdas help you overcome a limitation of generic types. Unfortunately, in another common situtation lambdas suffer from a different limitation. To understand the problem, recall the concept of type variance.

Suppose Employee is a subtype of Person. Is a List<Employee> a special case of a List<Person>? It seems that it should be. But actually, it would be unsound. Consider this code:

List<Employee> staff = ...;
List<Person> tenants = staff; // Not legal, but suppose it was
tenants.add(new Person("John Q. Public")); // Adds Person to staff!

Note that staff and tenants are references to the same list. To make this type error impossible, we must disallow the conversion from List<Employee> to List<Person>. We say that the type parameter T of List<T> is invariant.

If List was immutable, as it is in a functional programming language, then the problem would disappear, and one could have a covariant list. That is what is done in languages such as Scala. However, when generics were invented, Java had very few immutable generic classes, and the language designers instead embraced a different concept: use-site variance, or “wildcards.”

A method can decide to accept a List<? extends Person> if it only reads from the list. Then you can pass either a List<Person> or a List<Employee>. Or it can accept a List<? super Employee> if it only writes to the list. It is okay to write employees into aList<Person>, so you can pass such a list. In general, reading is covariant (subtypes are okay) and writing is contravariant (supertypes are okay). Use-site variance is just right for mutable data structures. It gives each service the choice which variance, if any, is appropriate.

However, for function types, use-site variance is a hassle. A function type is always contravariant in its arguments and covariant in its return value. For example, if you have a Function<Person, Employee>, you can safely pass it on to someone who needs a Function<Employee, Person>. They will only call it with employees, whereas your function can handle any person. They will expect the function to return a person, and you give them something even better.

In Java, when you declare a generic functional interface, you can’t specify that function arguments are always contravariant and return types always covariant. Instead, you have to repeat it for each use. For example, look at the javadoc for Stream<T>:

void forEach(Consumer<? super T> action)
Stream<T> filter(Predicate<? super T> predicate)
<R> Stream<R> map(Function<? super T, ? extends R> mapper)

The general rule is that you use super for argument types, extends for return types. That way, you can pass a Consumer<Object> to forEach on a Stream<String>. If it is willing to consume any object, surely it can consume strings.

But the wildcards are not always there. Look at

T reduce(T identity, BinaryOperator<T> accumulator)

Since T is the argument and return type of BinaryOperator, the type does not vary. In effect, the contravariance and covariance cancel each other out.

As the implementor of a method that accepts lambda expressions with generic types, you simply add ? super to any argument type that is not also a return type, and ? extends to any return type that is not also an argument type.

For example, consider the doInOrderAsync method of the preceding section. Instead of

public static <T> void doInOrderAsync(Supplier<T> first,
Consumer<T> second, Consumer<Throwable> handler)

it should be

public static <T> void doInOrderAsync(Supplier<? extends T> first,
Consumer<? super T> second, Consumer<? super Throwable> handler)

3.10. Monadic Operations

When you work with generic types, and with functions that yield values from these types, it is useful to supply methods that let you compose these functions—that is, carry out one after another. In this section, you will see a design pattern for providing such compositions.

Consider a generic type G<T> with one type parameter, such as List<T> (zero or more values of type T), Optional<T> (zero or one values of type T), or Future<T> (a value of type T that will be available in the future).

Also consider a function T -> U, or a Function<T, U> object.

It often makes sense to apply this function to a G<T> (that is, a List<T>, Optional<T>, Future<T>, and so on). How this works exactly depends on the nature of the generic type G. For example, applying a function f to a List with elements e₁,..., e_n means creating a list with elementsf(e₁),..., f(e_n).

Applying f to an Optional<T> containing v means creating an Optional<U> containing f(v). But if f is applied to an empty Optional<T> without a value, the result is an empty Optional<U>.

Applying f to a Future<T> simply means to apply it whenever it is available. The result is a Future<U>.

By tradition, this operation is usually called map. There is a map method for Stream and Optional. The CompletableFuture class that we will discuss in Chapter 6 has an operation that does just what map should do, but it is called thenApply. There is no map for a plainFuture<V>, but it is not hard to supply one (see Exercise 21).

So far, that is a fairly straightforward idea. It gets more complex when you look at functions T -> G<U> instead of functions T -> U. For example, consider getting the web page for a URL. Since it takes some time to fetch the page, that is a function URL -> Future<String>. Now suppose you have a Future<URL>, a URL that will arrive sometime. Clearly it makes sense to map the function to that Future. Wait for the URL to arrive, then feed it to the function and wait for the string to arrive. This operation has traditionally been called flatMap.

The name flatMap comes from sets. Suppose you have a “many-valued” function—a function computing a set of possible answers. And then you have another such function. How can you compose these functions? If f(x) is the set {y₁,..., y_n}, you apply g to each element, yielding {g(y₁),...,g(y_n)}. But each of the g(y_i) is a set. You want to “flatten” the set of sets so that you get the set of all possible values of both functions.

There is a flatMap for Optional<T> as well. Given a function T -> Optional<U>, flatMap unwraps the value in the Optional and applies the function, except if either the source or target option was not present. It does exactly what the set-based flatMap would have done on sets with size 0 or 1.

Generally, when you design a type G<T> and a function T -> U, think whether it makes sense to define a map that yields a G<U>. Then, generalize to functions T -> G<U> and, if appropriate, provide flatMap.