Void și colab.

"Bună, Amigo! Am un alt subiect mic și interesant pentru tine. Tipul Vidul."

"Și de ce ai avea nevoie de un astfel de tip? Adică, înțeleg void: este pentru a aduce funcții și proceduri în aliniere. Noi nu avem proceduri, dar avem funcții care returnează void (nimic)."

— Da, dar îți amintești că Ellie ți-a spus recent despre interfața Callable?

"Da."

„Și îți amintești și ce trebuie să treci ca argument de tip?”

„Da, tipul valorii returnate:”

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

"Corect. Și dacă vrei ca metoda de apel să returneze un int? Atunci?"

„Acum știu că există autoboxing pentru asta. Aș trece doar un număr întreg și totul va merge ca un ceas:”

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

„Excelent. Și dacă metoda nu returnează nimic?”

"Îți înțeleg punctul de vedere. Atunci folosim Void ca omologul lui void?"

"Da."

„Nu ar fi mai ușor să faci din valoarea returnată un Object și apoi să returnezi nul?”

— Uneori, dar nu întotdeauna.

„Știi că ai vrut cu adevărat să revii nul aici când ai scris Object, dar un alt programator s-ar putea să nu știe asta și să se gândească de ce returnezi null.”

„Sau codul care apelează metoda se va aștepta la o valoare returnată.”

„Dar când scrii Void, toată lumea înțelege imediat că acesta este un înveliș pentru void, chiar dacă totuși trebuie să returnezi null.”

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

"Hmm. Ai dreptate. O metodă care returnează întotdeauna null ridică întrebări. Dar metoda declarată ca Void poate face acest lucru fără a necesita explicații suplimentare."

"Lizibilitatea codului este pe primul loc. Îmi place Java!"

"Genial. Mă bucur că îți place. Am terminat pentru azi."