Void et al.

"Olá, amigo! Tenho outro tópico pequeno e interessante para você. O tipo Vazio."

"E por que você precisaria de tal tipo? Quero dizer, eu entendo void: é para alinhar funções e procedimentos. Não temos procedimentos, mas temos funções que retornam void (nada)."

"Sim, mas você se lembra que Ellie recentemente lhe falou sobre a interface Callable?"

"Sim."

"E você também se lembra do que precisa passar como argumento de tipo?"

"Sim, o tipo do valor de retorno:"

class EmptyJob implements Callable
{
 public String call() throws Exception
 {
  return null;
 }
}

"Certo. E se você quiser que o método call retorne um int? E então?"

"Agora eu sei que há autoboxing para isso. Eu apenas passaria um Integer e tudo funcionaria como um relógio:"

class EmptyJob implements Callable
{
 public Integer call() throws Exception
 {
  return null;
 }
}

"Excelente. E se o método não retornar nada?"

"Entendo. Então usamos o Vazio como a contraparte do Vazio?"

"Sim."

"Não seria mais fácil apenas tornar o valor de retorno um objeto e retornar nulo?"

"Às vezes, mas nem sempre."

"Você sabe que realmente pretendia retornar void aqui quando escreveu Object, mas outro programador pode não saber disso e pensará por que você está retornando null."

"Ou o código que chama o método esperará um valor de retorno."

"Mas quando você escreve Void, todos imediatamente entendem que este é um wrapper para void, mesmo que você ainda tenha que retornar null."

class EmptyJob implements Callable
{
 public Void call() throws Exception
 {
  return null;
 }
}

"Hmm. Você está certo. Um método que sempre retorna nulo levanta questões. Mas o método declarado como Void pode fazer isso sem exigir maiores explicações."

"A legibilidade do código vem em primeiro lugar. Eu gosto de Java!"

"Ótimo. Estou feliz que você gostou. Terminamos por hoje."