Was ist Serialisierung in Java?

Serialisierung (Serialization) verwendet man in Java, um einen Datenfluss (data stream) so umzuwandeln, dass es in eine Datei geschrieben und über das Netzwerk transportiert werden kann. Oder man speichert die Daten in einer Datenbank, wobei dann niemand den Inhalt lesen kann. De-Serialisierung ist dann das umgekehrte, man nimmt den Datenfluss und baut damit wieder die ursprünglichen Java Objekte.

Dabei muss der ganze Prozess nicht auf der gleichen Maschine stattfinden. Man kann durchaus ein Objekt auf dem Rechner A serialisieren und auf Rechner B de-serialisieren.

Wie markiere ich eine Klasse als serialisierbar?

Eine Klasse muss das Interface java.io.Serializable implementieren, um anzuzeigen, dass die Klasse bzw. die darin enthaltenen Attribute serialisiert werden können. Will man gewisse Attribute von der Serialisierung ausschliessen, verwendet man transient, also etwa:

private transient String name;

Und wie mache ich die eigentliche Serialisierung?

Ich schreibe bewusst von Streams, damit meine ich alle möglichen Java-Streams wie etwa der „FileOutputStream“ oder „ObjectOutputStream“. Jeder Daten-Stream wird nämlich vor dem Schreiben automatisch serialisiert.

Beispiel: Hat man eine serialisierbare Klasse, etwa „Kartoffel.java“ und schreibt dann eine Instanz einer Kartoffel in ein File, werden die Daten automatisch serialisiert (die Namenskonvention sagt übrigens, man soll eine *.ser Datei erstellen).

Dasselbe ist der Fall beim Einlesen der Daten und mappen auf die Kartoffelklasse. Man muss dann aber bedenken, dass Attribute, die als „transient“ deklariert wurden, ja nicht serialisiert wurden und somit keinen Wert erhalten können. Diese Attribute haben dann entweder 0 oder null als Inhalt.

Welche Formate werden in der Realität verwendet?

Meistens ist das Format der Serialisierung entweder JSON oder XML. Das bedeutet nicht, dass JSON Daten in irgendwas wie ABSDFJLKHSDKFJHKJSHDF serialisiert werden und dann wieder zurück – das ist zwar auch möglich, aber in diesem Beispiel mit JSON ist JSON die Serialisierung selber. Das bedeutet, wenn ich ein Java Objekt etwa über das Netzwerk schicke und irgendwo in den Optionen „JSON“ angebe, dann wird dieses Java Objekt vor dem Senden in das JSON Format serialisiert und beim Empfänger wieder zurück-serialisiert.

Hat das was zu tun mit dieser komischen serialVersionUID?

Genau, Eclipse will in einigen Fällen, dass man seiner Klasse eine serialVersionUID vergibt:

/** serialVersionUID. */
private static final long serialVersionUID = 1L;

Diese ist dazu da, damit Java verifizieren kann, dass beim Serialisieren oder De-serialisieren auch wirklich die gleiche Version einer Klasse verwendet wird. Falls dem nicht so ist, wird eine InvalidClassException geworfen. Das bedeutet aber auch, dass man die serialVersionUID jeweils anpassen müsste, wenn man signifikante Änderungen der Klasse vornimmt.

Normalerweise empfiehlt einem Eclipse, eine serialVersionUID zu erstellen, wenn man eine Exception verwendet – Exception implementiert Serializable und braucht daher vorzugsweise eine serialVersionUID.

Am einfachsten wäre es, wenn man bei der serialVersionUID bei 0 startet und immer +1 macht, wenn man etwas ändert, was die Serialisierung beeinflusst – Etwa wenn man ein Attribut hinzufügt oder entfernt.

Werbeanzeigen

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden /  Ändern )

Google Foto

Du kommentierst mit Deinem Google-Konto. Abmelden /  Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden /  Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden /  Ändern )

Verbinde mit %s