Vacío et al.

"¡Hola, amigo! Tengo otro tema pequeño e interesante para ti. El tipo del Vacío".

"¿Y por qué necesitarías un tipo así? Quiero decir, entiendo vacío: es para alinear funciones y procedimientos. No tenemos procedimientos, pero tenemos funciones que devuelven vacío (nada)".

"Sí, pero ¿recuerdas que Ellie te habló recientemente sobre la interfaz Callable?"

"Sí."

"¿Y también recuerdas lo que necesitas pasar como un argumento de tipo?"

"Sí, el tipo del valor de retorno:"

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

"Correcto. ¿Y si quieres que el método de llamada devuelva un int? ¿Entonces qué?"

"Ahora sé que hay autoboxing para esto. Simplemente pasaría un número entero y todo irá como un reloj:"

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

"Excelente. ¿Y si el método no devuelve nada?"

"Entiendo tu punto. ¿Entonces usamos Vacío como la contraparte de vacío?"

"Sí."

"¿No sería más fácil simplemente hacer que el valor de retorno sea un Objeto y luego devolver un valor nulo?"

"A veces, pero no siempre".

"Sabes que realmente tenías la intención de devolver void aquí cuando escribiste Object, pero es posible que otro programador no lo sepa y pensará por qué estás volviendo nulo".

"O el código que llama al método esperará un valor de retorno".

"Pero cuando escribes Void, todos entienden de inmediato que se trata de un envoltorio para void, aunque todavía tienes que devolver nulo".

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

"Hmm. Tienes razón. Un método que siempre devuelve nulo plantea preguntas. Pero el método declarado como Void puede hacer esto sin requerir más explicación".

"La legibilidad del código es lo primero. ¡Me gusta Java!"

"Genial. Me alegro de que te guste. Hemos terminado por hoy".