Void et al.

"Hej, Amigo! Jag har ett annat litet och intressant ämne till dig. Void-typen."

"Och varför skulle du behöva en sådan typ? Jag menar, jag förstår void: det är för att anpassa funktioner och procedurer. Vi har inga procedurer, men vi har funktioner som returnerar void (ingenting)."

"Japp, men kommer du ihåg att Ellie nyligen berättade om Callable-gränssnittet?"

"Ja."

"Och kommer du också ihåg vad du behöver för att passera som ett typargument?"

"Ja, typen av returvärde:"

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

"Rätt. Och tänk om du vill att anropsmetoden ska returnera en int? Vad då?"

"Nu vet jag att det finns autoboxning för detta. Jag skulle bara klara ett heltal, och allt kommer att gå som på räls:"

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

"Utmärkt. Och tänk om metoden inte ger något tillbaka?"

"Jag förstår din poäng. Då använder vi Void som motsvarighet till void?"

"Japp."

"Skulle det inte vara lättare att bara göra returvärdet till ett objekt och sedan returnera null?"

"Ibland, men inte alltid."

"Du vet att du verkligen menade att returnera ogiltig här när du skrev Object, men en annan programmerare kanske inte vet detta och kommer att tänka varför du returnerar null."

"Eller koden som anropar metoden förväntar sig ett returvärde."

"Men när du skriver Void förstår alla direkt att detta är ett omslag för void, även om du fortfarande måste returnera null."

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

"Hmm. Du har rätt. En metod som alltid returnerar null väcker frågor. Men metoden som förklarats som Void kan göra detta utan att behöva ytterligare förklaring."

"Kodläsbarhet kommer först. Jag gillar Java!"

"Jättebra. Jag är glad att du gillar det. Vi är klara för idag."