1. Overview
As Java developers, we might have encountered the Void type on some occasions and wondered what was its purpose.
In this quick tutorial, we’ll learn about this peculiar class and see when and how to use it as well as how to avoid using it when possible.
2. What’s the Void Type
Since JDK 1.1, Java provides us with the Void type. Its purpose is simply to represent the void return type as a class and contain a Class<Void> public value. It’s not instantiable as its only constructor is private.
Therefore, the only value we can assign to a Void variable is null. It may seem a little bit useless, but we’ll now see when and how to use this type.
3. Usages
There are some situations when using the Void type can be interesting.
3.1. Reflection
First, we could use it when doing reflection. Indeed, the return type of any void method will match the Void.TYPE variable that holds the Class<Void> value mentioned earlier.
Let’s imagine a simple Calculator class:
public class Calculator {
private int result = 0;
public int add(int number) {
return result += number;
}
public int sub(int number) {
return result -= number;
}
public void clear() {
result = 0;
}
public void print() {
System.out.println(result);
}
}
Some methods are returning an integer, some are not returning anything. Now, let’s say we have to retrieve, by reflection, all methods that don’t return any result. We’ll achieve this by using the Void.TYPE variable:
@Test
void givenCalculator_whenGettingVoidMethodsByReflection_thenOnlyClearAndPrint() {
Method[] calculatorMethods = Calculator.class.getDeclaredMethods();
List<Method> calculatorVoidMethods = Arrays.stream(calculatorMethods)
.filter(method -> method.getReturnType().equals(Void.TYPE))
.collect(Collectors.toList());
assertThat(calculatorVoidMethods)
.allMatch(method -> Arrays.asList("clear", "print").contains(method.getName()));
}
As we can see, only the clear() and print() methods have been retrieved.
3.2. Generics
Another usage of the Void type is with generic classes. Let’s suppose we are calling a method that requires a Callable parameter:
public class Defer {
public static <V> V defer(Callable<V> callable) throws Exception {
return callable.call();
}
}
But, the Callable we want to pass doesn’t have to return anything. Therefore, we can pass a Callable<Void>:
@Test
void givenVoidCallable_whenDiffer_thenReturnNull() throws Exception {
Callable<Void> callable = new Callable<Void>() {
@Override
public Void call() {
System.out.println("Hello!");
return null;
}
};
assertThat(Defer.defer(callable)).isNull();
}
As shown above, in order to return from a method with the Void return type, we just have to return null. Moreover, we could have either used a random type (such as Callable<Integer>) and return null or no type at all (Callable), but using Void states our intentions clearly.
We can also apply this method to lambdas. As a matter of fact, our Callable could have been written as a lambda. Let’s imagine a method requiring a Function, but we want to use a Function that doesn’t return anything. Then we just have to make it return Void:
public static <T, R> R defer(Function<T, R> function, T arg) {
return function.apply(arg);
}
@Test
void givenVoidFunction_whenDiffer_thenReturnNull() {
Function<String, Void> function = s -> {
System.out.println("Hello " + s + "!");
return null;
};
assertThat(Defer.defer(function, "World")).isNull();
}
4. How to Avoid Using It?
Now, we’ve seen some usages of the Void type. However, even if the first usage is totally fine, we might want to avoid using Void in generics if possible. Indeed, encountering a return type that represents the absence of a result and can only contain null can be cumbersome.
We’ll now see how to avoid these situations. First, let’s consider our method with the Callable parameter. In order to avoid using a Callable<Void>, we might offer another method taking a Runnable parameter instead:
public static void defer(Runnable runnable) {
runnable.run();
}
So, we can pass it a Runnable which doesn’t return any value and thus get rid of the useless return null:
Runnable runnable = new Runnable() {
@Override
public void run() {
System.out.println("Hello!");
}
};
Defer.defer(runnable);
But then, what if the Defer class is not ours to modify? Then we can either stick to the Callable<Void> option or create another class taking a Runnable and deferring the call to the Defer class:
public class MyOwnDefer {
public static void defer(Runnable runnable) throws Exception {
Defer.defer(new Callable<Void>() {
@Override
public Void call() {
runnable.run();
return null;
}
});
}
}
By doing that, we encapsulate the cumbersome part once and for all in our own method, allowing future developers to use a simpler API.
Of course, the same can be achieved for Function. In our example, the Function doesn’t return anything, thus we can provide another method taking a Consumer instead:
public static <T> void defer(Consumer<T> consumer, T arg) {
consumer.accept(arg);
}
Then, what if our function doesn’t take any parameters? We can either use a Runnable or create our own functional interface (if that seems clearer):
public interface Action {
void execute();
}
Then, we overload the defer() method again:
public static void defer(Action action) {
action.execute();
}
Action action = () -> System.out.println("Hello!");
Defer.defer(action);
5. Conclusion
In this short article, we covered the Java Void class. We saw what was its purpose and how to use it. We also learned some alternatives to its usage.
As usual, the full code of this article can be found over on GitHub.
