Alle Tabs der Lerneinheit (Erklärung · Interaktiv verstehen · Praxis-Übung · Klausur-Quiz) als durchgehender Text. Ideal zum Wiederholen vor der Klausur, und für Suchmaschinen wie Google, Bing und KI-Suche (ChatGPT, Perplexity).
Teil 1·Erklärung
Diese Lerneinheit wurde für typische Bachelor-Klausuren konzipiert. So prüfen wir · Fehler entdeckt? Melde ihn uns oder markiere die fragliche Stelle direkt im Text oben.
Alle Tabs der Lerneinheit (Erklärung · Interaktiv verstehen · Praxis-Übung · Klausur-Quiz) als durchgehender Text. Ideal zum Wiederholen vor der Klausur, und für Suchmaschinen wie Google, Bing und KI-Suche (ChatGPT, Perplexity).
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 arbeitentransient einsetzen (Felder vom Serialisieren ausschließen)serialVersionUID und das Versionsproblem (InvalidClassException) erklärenAbgrenzung: 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.
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.
Anmelden, um den Fortschritt zu speichern.
Nächster Schritt
Aktives Abrufen festigt Wissen schneller als nochmal lesen.
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 arbeitentransient einsetzen (Felder vom Serialisieren ausschließen)serialVersionUID und das Versionsproblem (InvalidClassException) erklärenAbgrenzung: 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.
Serialisierung wandelt ein Objekt (und alle Objekte, die es referenziert) in einen Byte-Strom um (
writeObject); Deserialisierung baut daraus wieder ein Objekt (readObject).
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.writeObjectschreibt,ObjectInputStream.readObjectliest (und gibtObjectzurück, daher der Cast). Implementiert die Klasse nichtSerializable, gibt es zur Laufzeit eineNotSerializableException.
Verfolge im Stepper, wie writeObject durch die Felder geht: inhaber und saldo wandern in den Byte-Strom, das transient-Feld pin wird übersprungen.
Interaktive Visualisierung
Interaktive Komponente: probiere sie im Topic-Player oben aus.
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.
Interaktive Visualisierung
Interaktive Komponente: probiere sie im Topic-Player oben aus.
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:
serialVersionUIDexplizit setzen.
readObject auf Daten aus unsicherer Quelle ist ein bekanntes Einfallstor (Deserialisierungs-Angriffe), beim Lesen kann beliebiger Code entstehen.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.
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.
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.
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.
Interaktive Visualisierung
Interaktive Komponente: probiere sie im Topic-Player oben aus.
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.
Klausurfragen mit Lösungen (6)
Antwort: Das Interface Serializable implementieren (Marker, ohne Methoden)
Erklärung: Serializable ist ein Marker-Interface ohne Methoden. Die Klasse signalisiert damit nur 'darf serialisiert werden'. writeObject/readObject erledigen die Arbeit. Ohne Serializable gibt es eine NotSerializableException.
Antwort: Das Feld wird NICHT serialisiert
Erklärung: transient schliesst ein Feld von der Serialisierung aus. Nach der Deserialisierung steht es auf seinem Default-Wert (null/0/false). Nutzung: Geheimnisse (Passwoerter), abgeleitete oder nicht-serialisierbare Felder.
Antwort: Falsch
Erklärung: Falsch. readObject rekonstruiert das Objekt direkt aus dem Byte-Strom, OHNE den Konstruktor aufzurufen. Logik oder Defaults, die nur im Konstruktor gesetzt werden, laufen also nicht.
Typ: Wahr/Falsch
Antwort: NotSerializableException, weil der ganze Graph serialisierbar sein muss
Erklärung: writeObject serialisiert den ganzen erreichbaren Objekt-Graphen. Ist eine referenzierte Klasse (Adresse) nicht Serializable, scheitert die ganze Operation mit NotSerializableException. Loesung: Adresse auch Serializable machen oder das Feld transient setzen.
Zuordnungen:
Erklärung: Serializable (Marker), transient (ausschliessen), serialVersionUID (Version), writeObject (schreiben). Das Kern-Vokabular der Serialisierung.
Typ: Zuordnung
Antwort: InvalidClassException, weil die generierte serialVersionUID nicht mehr passt
Erklärung: Ohne explizite serialVersionUID generiert der Compiler eine aus der Klassenstruktur. Aendert sich die Klasse, aendert sich die generierte UID, sie passt nicht mehr zu den alten Daten, InvalidClassException beim Laden. Deshalb serialVersionUID immer explizit setzen.
Klausurfragen mit Lösungen (6)
Antwort: Ein Objekt in einen Byte-Strom umwandeln (und zurück)
Erklärung: Serialisierung wandelt ein Objekt (und den erreichbaren Graphen) in einen Byte-Strom um, z.B. zum Speichern in einer Datei oder Senden ueber Netzwerk. Deserialisierung ist der Rueckweg. Hat nichts mit Sortieren oder Threads zu tun.
Antwort: writeObject() und readObject()
Erklärung: ObjectOutputStream.writeObject() schreibt ein Objekt in den Strom, ObjectInputStream.readObject() liest es (und gibt Object zurueck, daher der Cast). write()/read() sind die Byte-Methoden roher Streams, nicht objekt-orientiert.
Antwort: Falsch
Erklärung: Falsch. static-Felder gehoeren zur Klasse, nicht zum einzelnen Objekt, und werden NICHT mitserialisiert. Serialisiert werden nur die Instanz-Felder (ausser transient).
Typ: Wahr/Falsch
Lösungen pro Lücke:
Erklärung: Serializable (Marker), transient (ausschliessen), readObject (rekonstruiert ohne Konstruktor). Kern-Klausurwissen der Serialisierung.
Typ: Lückentext
Antwort: null
Erklärung: transient-Felder werden nicht serialisiert, stehen also nicht im Strom. Nach der Deserialisierung haben sie ihren Default-Wert: null bei Objektreferenzen (wie String), 0 bei int, false bei boolean.
Antwort: Java-Serialisierung ist fragil bei Klassenänderungen, unsicher bei fremden Daten und nur Java-intern lesbar
Erklärung: Java-native Serialisierung ist fragil (Klassenaenderung macht Daten unlesbar), ein Sicherheitsrisiko (Deserialisierungs-Angriffe bei untrusted Bytes) und nur von Java verstehbar. JSON/andere definierte Formate sind portabel und robuster. Java-Serialisierung ist nicht entfernt, aber mit Vorsicht zu nutzen.