Serialisierung von Objekten und Zuständen

Motivation: Persistierung von Objekten und Spielzuständen

public class Studi {
    private final int credits = 42;
    private String name = "Hilde";

    ...
}

Ich möchte ein Spiel (einen Lauf) im Dungeon abspeichern, um es später fortsetzen zu können. Wie kann ich den aktuellen Zustand (also Level, Monster, Held, Inventar, XP/Health/...) so speichern, dass ich später das Spiel nach einem Neustart einfach fortsetzen kann?

Serialisierung von Objekten

• Klassen müssen Marker-Interface Serializable implementieren

  "Marker-Interface": Interface ohne Methoden. Ändert das Verhalten des Compilers, wenn eine Klasse dieses Interface implementiert: Weitere Funktionen werden "freigeschaltet", beispielsweise die Fähigkeit, Klone zu erstellen (Cloneable) oder bei Serializable Objekte serialisierbar zu machen.

  Das ist in meinen Augen eine "Design-Sünde" in Java (neben der Einführung von null): Normalerweise definieren Interfaces eine Schnittstelle, die eine das Interface implementierende Klasse dann erfüllen muss. Damit agiert das Interface wie ein Typ. Hier ist das Interface aber leer, es wird also keine Schnittstelle definiert. Aber es werden damit stattdessen Tooling-Optionen aktiviert, was Interfaces vom Konzept her eigentlich nicht machen sollten/dürften - dazu gibt es Annotationen!

• Schreiben von Objekten (samt Zustand) in Streams

  ObjectOutputStream: void writeObject(Object)

  Die Serialisierung erfolgt dabei für alle Attribute (außer static und transient, s.u.) rekursiv.

  Dabei werden auch Zirkelreferenzen automatisch aufgelöst/unterbrochen.

• Lesen und "Wiedererwecken" der Objekte aus Streams

  ObjectInputStream: Object readObject()

  Dabei erfolgt KEIN Konstruktor-Aufruf!

Einfaches Beispiel

public class Studi implements Serializable {
    private final int credits = 42;
    private String name = "Hilde";

    public static void writeObject(Studi studi, String filename) {
        try (FileOutputStream fos = new FileOutputStream(filename);
            ObjectOutputStream oos = new ObjectOutputStream(fos)) {
            oos.writeObject(studi);    oos.close();
        } catch (IOException ex) {}
    }

    public static Studi readObject(String filename) {
        Studi studi = null;
        try (FileInputStream fis = new FileInputStream(filename);
            ObjectInputStream ois = new ObjectInputStream(fis)) {
            studi = (Studi) ois.readObject();    ois.close();
        } catch (IOException | ClassNotFoundException ex) {}
        return studi;
    }
}

Bedingungen für Objekt-Serialisierung

• Klassen implementieren Marker-Interface Serializable
• Alle Attribute müssen ebenfalls serialisierbar sein (oder Deklaration "transient")
• Alle primitiven Typen sind per Default serialisierbar
• Es wird automatisch rekursiv serialisiert, aber jedes Objekt nur einmal (bei Mehrfachreferenzierung)
• Serialisierbarkeit vererbt sich

Ausnahmen

• Als static deklarierte Attribute werden nicht serialisiert
• Als transient deklarierte Attribute werden nicht serialisiert
• Nicht serialisierbare Attribut-Typen führen zu NotSerializableException

Version-UID

static final long serialVersionUID = 42L;

• Dient zum Vergleich der serialisierten Version und der aktuellen Klasse
• Über IDE generieren oder manuell vergeben
• Wenn das Attribut fehlt, wird eine Art Checksumme von der Runtime-Umgebung berechnet (basierend auf diversen Eigenschaften der Klasse)

Dieser Wert wird beim Einlesen verglichen: Das Objekt wird nur dann wieder de-serialisiert, wenn die serialVersionUID mit der einzulesenden Klasse übereinstimmt!

Bei automatischer Berechnung der serialVersionUID durch die JVM kann jede kleine Änderung an der Klasse (beispielsweise Refactoring: Änderung der Methodennamen) eine neue serialVersionUID zur Folge haben. Das würde bedeuten, dass bereits serialisierte Objekte nicht mehr eingelesen werden können, auch wenn sich nur Methoden o.ä. verändert haben und die Attribute noch so vorhanden sind. Deshalb bietet es sich an, hier selbst eine serialVersionUID zu definieren - dann muss man aber auch selbst darauf achten, diese zu verändern, wenn sich wesentliche strukturelle Änderungen an der Klasse ergeben!

Bemerkungen

Es existieren diverse weitere Fallstricke und Probleme, siehe [Bloch2018] Kapitel 11 "Serialization".

Man kann in den ObjectOutputStream nicht nur ein Objekt schreiben, sondern mehrere Objekte und Variablen schreiben lassen. In dieser Reihenfolge muss man diese dann aber auch wieder aus dem Stream herauslesen (vgl. Object Streams).

Man kann die zu serialisierenden Attribute mit der Annotation @Serial markieren. Dies ist in der Wirkung ähnlich zu @Override: Der Compiler prüft dann, ob die markierten Attribute wirklich serialisierbar sind und würde sonst zur Compile-Zeit einen Fehler werfen.

Weitere Links:

• Tutorials:
  • https://docs.oracle.com/en/java/javase/17/docs/specs/serialization/input.html
  • https://www.baeldung.com/java-serialization
• API:
  • https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/io/ObjectOutputStream.html
  • https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/io/ObjectInputStream.html
  • https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/io/Serializable.html

Wrap-Up

• Markerinterface Serializable schaltet Serialisierbarkeit frei

• Objekte schreiben: ObjectOutputStream: void writeObject(Object)

• Objekte lesen: ObjectInputStream: Object readObject()

• Wichtigste Eigenschaften:

  • Attribute müssen serialisierbar sein
  • transient und static Attribute werden nicht serialisiert
  • De-Serialisierung: KEIN Konstruktor-Aufruf!
  • Serialisierbarkeit vererbt sich
  • Objekt-Referenz-Graph wird automatisch beachtet