OOP 27.6: Serialisierung

Axel Rogat

Objektorientiertes Programmieren mit C++ und JAVA

28: JAVA im Netz

27.6 Serialisierung

Dieser in JAVA 1.1 eingeführte Mechanismus dient zum Schreiben und Laden kompletter Objekte in/aus Dateien ("Serialisieren" und "Deserialisieren"). Es werden alle Member abgespeichert, auch private und solche, die aus Oberklassen geerbt wurden. Wenn ein Objekt andere Objekte referenziert, werden auch diese automatisch mit abgespeichert (rekursive Serialisierung). Daher stammt der Name: alle zusammengehörigen Daten (ein ganzer Objekt-/Unterobjekt-Baum) werden serialisiert, um in die sequentielle Struktur einer Datei zu passen.

Objekte müssen also nicht bei jeder I/O-Operation explizit in ihre Bestandteile (letztendlich primitive Typen) zerlegt und ein passendes Dateiformat entworfen zu werden. Programmen, die mit Grafiken und Textdarstellungen arbeiten, erhalten so automatisch ein Ein-/Ausgabe-Format, das nicht ausdrücklich programmiert zu werden braucht. Applets können durch Deserialisierung in den Viewer oder Browser geladen werden. Außerdem kann die Serialisierung problemlos mit Zip-Streams gekoppelt werden.

Klassen, für die dies möglich sein soll, brauchen dazu nur Serializable (ein reines Marker-Interface) zu implementieren. Wenn andere Klassen gelayert werden, müssen diese natürlich auch Serializable sein. Der Versuch, eine nicht serialisierbare Klasse zu serialisieren, löst eine NotSerializableException aus.
Eventuell ist es nicht sinnvoll, alle Member eine Klasse hinauszuschreiben, beispielsweise sehr flüchtige Informationen wie die aktuelle Mausposition. Solche Member können durch das Schlüsselwort transient ("vergänglich") markiert werden. Sie werden nicht geschrieben und beim Laden mit 0 initialisiert.
Der Mechanismus speichert automatisch alle (nicht-transienten) Datenmember des Objekts ab. Die Daten landen nicht einfach binär sequentiell in der Datei, in einem bestimmten Format werden die Namen der Member mit abgelegt.
Die verwendeten Streams heißen ObjectInputStream und ObjectOutputStream, die Methoden readObject und writeObject.

: public class ObjectInputStream extends InputStream implements ObjectInput, ObjectStreamConstants { public ObjectInputStream(InputStream in) throws IOException, StreamCorruptedException; public final Object readObject() throws OptionalDataException, ClassNotFoundException, IOException; } public class ObjectOutputStream extends OutputStream implements ObjectOutput, ObjectStreamConstants { public ObjectOutputStream(OutputStream out) throws IOException; public final void writeObject(Object obj) throws IOException; }

Manchmal ist es sinnvoll, die Serialisierung selbst zu übernehmen, beispielsweise, wenn einige Member von System zu System unterschiedliche Default-Werte haben sollen, oder wenn eine Oberklasse oder referenzierte Klasse nicht Serializable ist. Dazu definiert man für die betroffene Klasse die Methoden writeObject(ObjectOutputStream) und readObject(ObjectInputStream).
Klassen verändern sich oft im Lauf ihrer Entwicklung, so daß es sinnvoll ist, in den Objektstrom nicht nur den Namen der Klasse, sondern auch eine Versionsnummer zu schreiben.
Wenn die Klasse eine Konstante static final long serialVersionUID definiert, wird dieser Wert als Versionsnummer benutzt. Ansonsten wird automatisch ein Wert verwendet, der aus den Zeichen im Klassennamen und in den Methodennamen berechnet wird. Mit dem Utility serialver kann man ihn berechnen und ausgeben.
Auch wenn nur kleine Änderungen durchgeführt werden, würde sich mit großer Wahrscheinlichkeit der berechnete Wert ändern. Wenn Objekte dennoch über Serialisation austauschbar sein sollen, sollte man die Konstante definieren.
Es gibt ein weiteres Interface, Externalizable, mit dem eine Klasse die Serialisierung in Ablauf und Format komplett selbst übernehmen kann. Es ist kein Marker-Interface, sondern enthält die Methoden readExternal und writeExternal. Klassen, die sich in einem Format serialisieren wollen, das sich vollständig vom Standard unterscheidet, sollten dieses Interface wählen.

: public interface Externalizable extends java.io.Serializable { void writeExternal(ObjectOutput out) throws IOException; void readExternal(ObjectInput in) throws IOException, ClassNotFoundException; }

Beispiel: Wir serialisieren einen Vektor aus Strings mit einem Befehl. Die erste Funktion schreibt den Vektor in eine Datei, die zweite restauriert den Vektor aus dieser Datei und gibt ihn aus.

: static void toDisk() { Vector v=new Vector(10); v.addElement("A Midsummer-Night's Dream"); v.addElement("Much Ado about Nothing"); v.addElement("The Comedy of Errors"); v.addElement("The Merry Wives of Windsor"); v.addElement("The Taming of the Shrew"); try { new ObjectOutputStream( new FileOutputStream("vector.ser")).writeObject(v); } catch (Exception e) { System.err.println("sorry: "+e); } } static void fromDisk() { try { Vector v=(Vector)new ObjectInputStream( new FileInputStream("vector.ser")).readObject(); System.out.println(v); } catch (Exception e) { System.err.println("sorry: "+e); } }

Die erzeugte Datei vector.ser sieht wie folgt aus (nicht druckbare Zeichen durch . ersetzt):

: ....sr..java.util.Vector..[.;.....I..capacityIncrementI..elemen tCount[..elementDatat..[Ljava/lang/Object;xp........ur..[Ljava.l ang.Object;..X..s)l...xp....t..A Midsummer-Night's Dreamt Much Ado about Nothingt The Comedy of Errorst The Merry Wives of Wi ndsort The Taming of the Shrewppppp

Man erkennt beispielsweise den Namen der serialisierten Klasse Vector und die Namen ihrer Daten-Member.

Auch Applets können serialisiert werden. Dabei ist zu beachten, daß sie vor dem Abspeichern gestoppt werden müssen. Sie können dann auf spezielle Weise in den Browser geladen werden. Nach dem Laden müssen sie neu gestartet werden, was die Browser üblicherweise automatisch tun.

27.5: Datenkompression Startseite 28: JAVA im Netz