Void et al.

"Hallo, Amigo! Ik heb nog een klein en interessant onderwerp voor je. Het Void-type."

"En waarom zou je zo'n type nodig hebben? Ik bedoel, ik begrijp leegte: het is om functies en procedures op één lijn te brengen. We hebben geen procedures, maar we hebben functies die leegte (niets) retourneren."

"Ja, maar weet je nog dat Ellie je onlangs vertelde over de Callable-interface?"

"Ja."

"En weet je ook nog wat je als typeargument moet doorgeven?"

"Ja, het type retourwaarde:"

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

"Juist. En wat als je wilt dat de call-methode een int retourneert? Wat dan?"

"Nu weet ik dat er autoboxing voor is. Ik zou gewoon een geheel getal doorgeven en alles zal op rolletjes lopen:"

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

"Uitstekend. En wat als de methode niets teruggeeft?"

'Ik snap je punt. Gebruiken we dan Leegte als de tegenhanger van leegte?'

"Ja."

"Zou het niet eenvoudiger zijn om van de geretourneerde waarde een Object te maken en vervolgens null terug te geven?"

"Soms, maar niet altijd."

"Je weet dat je echt van plan was om hier void terug te geven toen je Object schreef, maar een andere programmeur weet dit misschien niet en zal denken waarom je null retourneert."

"Of de code die de methode aanroept, verwacht een retourwaarde."

"Maar als je Void schrijft, begrijpt iedereen meteen dat dit een omhulsel is voor void, ook al moet je null teruggeven."

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

"Hmm. Je hebt gelijk. Een methode die altijd null retourneert, roept vragen op. Maar de methode die is gedeclareerd als Void kan dit doen zonder verdere uitleg."

"Leesbaarheid van de code komt op de eerste plaats. Ik hou van Java!"

'Geweldig. Ik ben blij dat je het leuk vindt. We zijn klaar voor vandaag.'