Void et al.

"Hei, Amigo! Jeg har et annet lite og interessant emne til deg. Void-typen."

"Og hvorfor skulle du trenge en slik type? Jeg mener, jeg forstår void: det er for å bringe funksjoner og prosedyrer på linje. Vi har ikke prosedyrer, men vi har funksjoner som returnerer void (ingenting)."

"Ja, men husker du at Ellie nylig fortalte deg om Callable-grensesnittet?"

"Ja."

"Og husker du også hva du trenger for å bestå som et typeargument?"

"Ja, typen returverdi:"

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

"Riktig. Og hva om du vil at anropsmetoden skal returnere en int? Hva da?"

"Nå vet jeg at det er autoboksing for dette. Jeg ville bare passert et heltall, og alt vil gå som smurt:"

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

"Utmerket. Og hva om metoden ikke gir noe tilbake?"

"Jeg forstår poenget ditt. Da bruker vi Void som motstykke til void?"

"Japp."

"Ville det ikke være lettere å bare gjøre returverdien til et objekt og deretter returnere null?"

"Noen ganger, men ikke alltid."

"Du vet at du egentlig mente å returnere ugyldig her da du skrev Object, men en annen programmerer vet kanskje ikke dette og vil tenke hvorfor du returnerer null."

"Eller koden som kaller metoden vil forvente en returverdi."

"Men når du skriver Void, forstår alle umiddelbart at dette er en innpakning for void, selv om du fortsatt må returnere null."

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

"Hmm. Du har rett. En metode som alltid returnerer null reiser spørsmål. Men metoden som er erklært som Void kan gjøre dette uten å kreve ytterligere forklaring."

"Kodelesbarhet kommer først. Jeg liker Java!"

"Flott. Jeg er glad du liker det. Vi er ferdige for i dag."