Im Java Magazin vom Juli 2017 wurde im Artikel über das Projekt „vavr“ die Klasse „Option“ erwähnt, die die Java-8-Optionals ergänzt und – hurra – serialisierbar ist. Warum ist „Optional“ selbst eigentlich nicht serialisierbar?

Zunächst einmal ist Optional als Monade keine Datenstruktur, sondern ein Container der eine Verarbeitung repräsentiert. Ähnlich einem Java-Stream der dazu dient Mengen von Objekten zu verarbeiten, aber nicht zu speichern. So ist der Stream nach Gebrauch verbraucht und nicht mehr zu verwenden, für die nächste Verarbeitung muß ein neuer her.

Oder anders ausgedrückt: Das Bierfaß bleibt in den Keller, nicht der Rollkutscher der es gebracht hat… Zum anderen ist da das Ding mit null. Optionals sollen es ja ermöglichen, daß man null-Werte in gleicher Weise verarbeiten kann wie „richtige“ Objekte die nicht null sind. Bei der Deserialisierung muß man das beachten und gegebenenfalls auf das Fehlen des Objekts reagieren. Aus Java-Sicht ist aber auch Optional ein Objekt und kann „null“ sein; bei der Deserialisierung hat man also nichts gewonnen, sondern muß neben dem Fall „Optional enthält null“ eben auch den Fall „Optional ist null“ berücksichtigen. Also besser ohne Optional einpacken und beim Auspacken gleich in ein Optional stecken.

Aus dem gleichen Grund übergibt man Optionals normalerweise auch nicht als Parameter an Methoden. Funktionen die Optionals als Ergebnis liefern sind hingegen ok – wer allerdings eine solche Methode mit dem Ergebnis „null“ verenden läßt, sollte besser den Job wechseln…