Serialisierung.

Ein Objekt lebt im Arbeitsspeicher. Sobald das Programm endet, ist es weg. Serialisierung verwandelt ein Objekt in einen Byte-Strom, den man in eine Datei schreiben, über das Netzwerk schicken oder später wieder einlesen kann. Deserialisierung ist der Rückweg: aus den Bytes entsteht wieder ein Objekt. Java bringt das eingebaut mit, über das Marker-Interface Serializable.

Was du können musst:

• Serializable implementieren und mit writeObject / readObject arbeiten
• verstehen, dass der ganze erreichbare Objekt-Graph mitserialisiert wird
• transient einsetzen (Felder vom Serialisieren ausschließen)
• serialVersionUID und das Versionsproblem (InvalidClassException) erklären
• wissen, warum man Java-Serialisierung heute oft meidet

Abgrenzung: hier die Grundlagen der Java-Objekt-Serialisierung. Externe Formate (JSON via Jackson/Gson, Protobuf) sind ein eigenes Thema, werden aber als bevorzugte Alternative erwähnt.

Die Idee in einem Satz

Serialisierung wandelt ein Objekt (und alle Objekte, die es referenziert) in einen Byte-Strom um (writeObject); Deserialisierung baut daraus wieder ein Objekt (readObject).

Das Marker-Interface Serializable

Serializable hat keine Methoden, es ist nur eine Markierung ("dieses Objekt darf serialisiert werden"):

class Konto implements Serializable {
    private static final long serialVersionUID = 1L;
    String inhaber = "Anna";
    int saldo = 500;
    transient String pin = "1234";   // wird NICHT serialisiert
}

// Schreiben
try (var out = new ObjectOutputStream(new FileOutputStream("konto.ser"))) {
    out.writeObject(konto);
}

// Lesen
try (var in = new ObjectInputStream(new FileInputStream("konto.ser"))) {
    Konto k = (Konto) in.readObject();
}

ObjectOutputStream.writeObject schreibt, ObjectInputStream.readObject liest (und gibt Object zurück, daher der Cast). Implementiert die Klasse nicht Serializable, gibt es zur Laufzeit eine NotSerializableException.

Was wird serialisiert, was nicht

Verfolge im Stepper, wie writeObject durch die Felder geht: inhaber und saldo wandern in den Byte-Strom, das transient-Feld pin wird übersprungen.

Deserialisierung: der Rückweg

readObject baut aus den Bytes wieder ein Objekt. Wichtig: der Konstruktor läuft dabei nicht, das Objekt wird direkt rekonstruiert. Und das transient-Feld, das nie geschrieben wurde, hat danach seinen Default-Wert.

serialVersionUID und die Versionsfalle

Jede serialisierbare Klasse hat eine serialVersionUID, eine Versionsnummer. Beim Deserialisieren prüft Java, ob die UID der gespeicherten Daten zur aktuellen Klasse passt. Tut sie das nicht (weil sich die Klasse geändert hat), gibt es eine InvalidClassException.

private static final long serialVersionUID = 1L;

Gibt man keine an, generiert der Compiler eine aus der Klassenstruktur. Ändert man dann die Klasse (Feld hinzufügen), ändert sich die generierte UID, und alte gespeicherte Objekte lassen sich nicht mehr laden. Deshalb: serialVersionUID explizit setzen.

Warum Java-Serialisierung mit Vorsicht zu genießen ist

• Fragil: jede Klassenänderung kann gespeicherte Daten unlesbar machen.
• Unsicher: readObject auf Daten aus unsicherer Quelle ist ein bekanntes Einfallstor (Deserialisierungs-Angriffe), beim Lesen kann beliebiger Code entstehen.
• Java-spezifisch: das Format versteht nur Java, kein Austausch mit anderen Sprachen.

Best Practice (Bloch, Effective Java): für Datenaustausch und Persistenz heute meist JSON oder ein anderes definiertes Format statt Java-nativer Serialisierung. Java-Serialisierung nur, wenn man sie wirklich braucht, und nie auf Bytes aus unsicherer Quelle.

Klausur-Faustregeln

1. Serialisierung = Objekt zu Byte-Strom, Deserialisierung = zurück. writeObject schreibt, readObject liest. Die Klasse muss Serializable implementieren (Marker-Interface, keine Methoden).

2. Der ganze erreichbare Objekt-Graph wird mitserialisiert. Referenziert ein Objekt andere, werden die mitgeschrieben. Alle beteiligten Klassen müssen Serializable sein, sonst NotSerializableException.

3. transient schließt ein Feld aus. Für Geheimnisse (Passwörter), abgeleitete oder nicht-serialisierbare Felder. Nach der Deserialisierung steht das Feld auf seinem Default.

4. readObject ruft keinen Konstruktor. Das Objekt wird direkt aus dem Strom gebaut.

5. serialVersionUID explizit setzen. Sie identifiziert die Klassen-Version. Passt sie nicht zu den gespeicherten Daten, gibt es InvalidClassException.

6. static wird nicht serialisiert. Statische Felder gehören zur Klasse, nicht zum Objekt, und landen nicht im Strom.

Häufige Stolpersteine

1. Vergessenes Serializable. Wenn die Klasse (oder eine referenzierte Klasse im Graph) Serializable nicht implementiert, knallt es zur Laufzeit mit NotSerializableException.

2. transient-Feld nach dem Laden erwartet. Es ist null/0/false, weil es nie im Strom war. Wer den Wert braucht, muss ihn nach readObject neu berechnen oder setzen.

3. serialVersionUID weggelassen. Der Compiler generiert eine; ändert sich die Klasse, passt sie nicht mehr, alte Daten werfen InvalidClassException.

4. Konstruktor-Logik erwartet. Bei readObject läuft kein Konstruktor, also auch keine dort gesetzten Defaults oder Validierungen.

5. static mit transient verwechseln. Beide landen nicht im Strom, aber aus verschiedenen Gründen: static gehört zur Klasse, transient ist bewusst ausgeschlossen.

6. Blindes Deserialisieren fremder Daten. readObject auf Bytes aus unsicherer Quelle ist ein Sicherheitsrisiko. Niemals untrusted Input naiv deserialisieren.

Der Objekt-Graph wandert mit

Ein Objekt referenziert oft andere Objekte. writeObject serialisiert nicht nur das eine Objekt, sondern den ganzen erreichbaren Graphen. Im Stepper hält eine Person eine Adresse, und beim Serialisieren der Person landet die Adresse automatisch mit im Strom.

Klausur-Tipp: Typische Fragen: (1) "Was bewirkt transient?" → Feld wird nicht serialisiert, ist danach Default. (2) "Was passiert, wenn eine referenzierte Klasse nicht Serializable ist?" → NotSerializableException. (3) "Wozu serialVersionUID?" → Versionskontrolle, sonst InvalidClassException bei Klassenänderung.