Challenges in Java 8

1. Overview

Java 8 introduced some new features, which revolved mostly around the use of lambda expressions. In this quick article, we’re going to take a look at downsides of some of them.

And, while this is not a full list, it’s a subjective collection of the most common and popular complaints regarding new features in Java 8.

2. Java 8 Stream and Thread Pool

First of all, Parallel Streams are meant to make easy parallel processing of sequences possible, and that works quite OK for simple scenarios.

The Stream uses the default, common ForkJoinPool – splits sequences into smaller chunks and performs operations using multiple threads.

However, there is a catch. There’s no good way to specify which ForkJoinPool to use and therefore, if one of the threads gets stuck all the other ones, using the shared pool, will have to wait for the long-running tasks to complete.

Fortunately, there is a workaround for that:

ForkJoinPool forkJoinPool = new ForkJoinPool(2);
forkJoinPool.submit(() -> /*some parallel stream pipeline */)
  .get();

This will create a new, separate ForkJoinPool and all tasks generated by the parallel stream will use the specified pool and not in the shared, default one.

It’s worth noting that there is another potential catch: “this technique of submitting a task to a fork-join pool, to run the parallel stream in that pool is an implementation ‘trick’ and is not guaranteed to work”, according to Stuart Marks – Java and OpenJDK developer from Oracle. An important nuance to keep in mind when using this technique.

3. Decreased Debuggability

The new coding style simplifies our source code, yet can cause headaches while debugging it.

First of all, let’s look at this simple example:

public static int getLength(String input) {
    if (StringUtils.isEmpty(input) {
        throw new IllegalArgumentException();
    }
    return input.length();
}

List lengths = new ArrayList();

for (String name : Arrays.asList(args)) {
    lengths.add(getLength(name));
}

This is a standard imperative Java code that’s self-explanatory.

If we pass empty String as an input – as a result – the code will throw an exception, and in debug console, we can see:

at LmbdaMain.getLength(LmbdaMain.java:19)
at LmbdaMain.main(LmbdaMain.java:34)

Now, let’s re-write the same code using Stream API and see what happens when an empty String gets passed:

Stream lengths = names.stream()
  .map(name -> getLength(name));

The call stack will look like:

at LmbdaMain.getLength(LmbdaMain.java:19)
at LmbdaMain.lambda$0(LmbdaMain.java:37)
at LmbdaMain$$Lambda$1/821270929.apply(Unknown Source)
at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
at java.util.Spliterators$ArraySpliterator.forEachRemaining(Spliterators.java:948)
at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:512)
at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:502)
at java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708)
at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
at java.util.stream.LongPipeline.reduce(LongPipeline.java:438)
at java.util.stream.LongPipeline.sum(LongPipeline.java:396)
at java.util.stream.ReferencePipeline.count(ReferencePipeline.java:526)
at LmbdaMain.main(LmbdaMain.java:39)

That’s the price we pay for leveraging multiple abstraction layers in our code. However, IDEs already developed solid tools for debugging Java Streams.

4. Methods Returning Null or Optional

Optional was introduced in Java 8 to provide a type-safe way of expressing optionality.

Optional, indicates explicitly that the return value may be not present. Hence, calling a method may return a value, and Optional is used to wrap that value inside – which turned out to be handy.

Unfortunately, because of the Java backward compatibility, we sometimes ended up with Java APIs mixing two different conventions. In the same class, we can find methods returning nulls as well as methods returning Optionals.

5. Too Many Functional Interfaces

In the java.util.function package, we have a collection of target types for lambda expressions. We can distinguish and group them as:

• Consumer – represents an operation that takes some arguments and returns no result
• Function – represents a function that takes some arguments and produces a result
• Operator – represents an operation on some type arguments and returns a result of the same type as the operands
• Predicate – represents a predicate (boolean-valued function) of some arguments
• Supplier – represents a supplier that takes no arguments and returns results

Additionally, we’ve got additional types for working with primitives:

• IntConsumer
• IntFunction
• IntPredicate
• IntSupplier
• IntToDoubleFunction
• IntToLongFunction
• … and same alternatives for Longs and Doubles

Furthermore, special types for functions with the arity of 2:

• BiConsumer
• BiPredicate
• BinaryOperator
• BiFunction

As a result, the whole package contains 44 functional types, which can certainly start being confusing.

6. Checked Exceptions and Lambda Expressions

Checked exceptions have been a problematic and controversial issue before Java 8 already. Since the arrival of Java 8, the new issue arose.

Checked exceptions must be either caught immediately or declared. Since java.util.function functional interfaces do not declare throwing exceptions, code that throws checked exception will fail during compilation:

static void writeToFile(Integer integer) throws IOException {
    // logic to write to file which throws IOException
}

List<Integer> integers = Arrays.asList(3, 9, 7, 0, 10, 20);
integers.forEach(i -> writeToFile(i));

One way to overcome this problem is to wrap checked exception in a try-catch block and rethrow RuntimeException:

List<Integer> integers = Arrays.asList(3, 9, 7, 0, 10, 20);
integers.forEach(i -> {
    try {
        writeToFile(i);
    } catch (IOException e) {
        throw new RuntimeException(e);
    }
});

This will work. However, throwing RuntimeException contradicts the purpose of checked exception and makes the whole code wrapped with boilerplate code, which we’re trying to reduce by leveraging lambda expressions. One of the hacky solutions is to rely on the sneaky-throws hack.

Another solution is to write a Consumer Functional Interface – that can throw an exception:

@FunctionalInterface
public interface ThrowingConsumer<T, E extends Exception> {
    void accept(T t) throws E;
}

static <T> Consumer<T> throwingConsumerWrapper(
  ThrowingConsumer<T, Exception> throwingConsumer) {
  
    return i -> {
        try {
            throwingConsumer.accept(i);
        } catch (Exception ex) {
            throw new RuntimeException(ex);
        }
    };
}

Unfortunately, we’re still wrapping the checked exception in a runtime exception.

Finally, for an in-depth solution and explanation of the problem, we can explore the following deep-dive: Exceptions in Java 8 Lambda Expressions.

8. Conclusion

In this quick write-up, we discussed some of the downsides of Java 8.

While some of them were deliberate design choices made by Java language architects and in many cases there is a workaround or alternative solution; we do need to be aware of their possible problems and limitations.