Ein weiterer Mechanismus, der in der JavaBeans-Spezifikation festgelegt ist, ist das Persistenzkonzept. Unter Persistenz versteht man, dass eine Komponente ihren Inhalt durch Serialisierung persistent (dauerhaft) speichern kann. Zum Inhalt dieser Komponente gehören in diesem Zusammenhang die Eigenschaften und die übrigen durch die JavaBeans-Komponente repräsentierten Daten, wie bspw. Bilddaten oder Audiodateien. Durch die Serialisierung von Komponenten wird eine einheitliche Schnittstelle festgelegt, wodurch JavaBeans-Komponenten ihren Inhalt bspw. auf der Festplatte abspeichern können. Die Daten werden hierbei durch spezielle API-Klassen gesammelt und an Streams weitergegeben. Die Serialisierungsspezifikation von JavaBeans gewährleistet daher, dass der Inhalt einer JavaBeans-Komponente nach einem einheitlichen Verfahren abgespeichert wird und somit zu einem späteren Zeitpunkt wieder geladen werden kann.
Durch das Persistenzkonzept wird es möglich, dass der Zustand einer Komponente jederzeit wieder hergestellt werden kann
Zusätzlich existiert in Java der Externalisierungsmechanismus, mit dem der Entwickler das Format der Datenspeicherung einer Komponenten manipulieren kann. Hiermit wird erreicht, dass die Daten einer JavaBeans-Komponente in einem bestimmten Dateiformat gespeichert werden, das von anderen JavaBeans-Komponenten oder Programmen gelesen werden kann.
Abb. 9.14: Speicherung und Wiederherstellung von persistenten Komponenten
Um den Serialisierungsprozess fehlerfrei durchführen zu können, müssen folgende Regeln beachtet werden:
- Nur Objekte, die die Interfaces java.io.Serializable- oder java.io.Externalizable implementieren, können serialisiert werden.
- Alle Objekte eines Beans, das die Serializable-Schnittstelle implementiert, müssen serialisierbar sein, da ansonsten der Serialisierungsmechanismus eine Ausnahme vom Typ NotSerializableException erzeugt.
- Der Serialisierungsprozess durchläuft die Beans-Hierarchie von oben nach unten.
- Für die Klassen, die wieder hergestellt werden müssen, gelten die üblichen Sicherheitsbestimmungen, wie bspw. Code-Verifikation und Security-Management.
- Die statischen Variablen einer JavaBeans-Komponente unterliegen dem Serialisierungsprozess nicht.
- Soll ein bestimmter Datentyp nicht serialisiert werden, so muss er mit dem Schlüsselwort transient explizit angegeben werden. Im folgenden Beispiel wird die Eigenschaft OperatingSystem nicht serialisiert, da für sie das Schlüsselwort transient deklariert wird:
String transient OperatingSystem= " "
Zur Serialisierung werden eine Reihe von Klassen verwendet. Die wichtigsten dieser Klassen sind hierbei ObjectInputStream zum Lesen von Daten aus einem InputStream-Objekt und ObjectOutputStream zum Schreiben der Daten in ein OutputStream-Objekt. Diese Klassen sind deshalb als Streams realisiert, um komplexe Objekte, und nicht lediglich einfache Datentypen wie Byte oder int, übermitteln zu können. Der Mechanismus der Persistenz von Objekten ist leicht implementierbar und erweiterbar, da hierzu lediglich die Schnittstelle Serializable zu implementieren ist. Hieraus ergibt sich keine Änderung des Programms, da keine Methoden implementiert werden müssen.
Die Klassen ObjectInputStream und ObjectOutputStream
Objekte können mit der Klasse ObjectOutputStream in ein OutputStream-Objekt geschrieben werden. Diese Objekte können dann wie gewöhnliche Streams bearbeitet werden. Objekte können folglich in eine Datei geschrieben oder über ein Netzwerk übertragen werden. Üblicherweise werden serialisierte Objekte mit der Methode writeObject() in eine Datei mit dem Suffix .ser gespeichert, eine Abkürzung für das Wort Serialisierung. Die Objekte müssen von einem ObjectInputStream-Objekt in der Reihenfolge gelesen werden, in der sie von der Methode writeObject() Methode geschrieben wurden. Der voreingestellte Serialisierungsmechanismus für ein Objekt speichert dann den Klassennamen, die Klassensignatur und alle nichttransient und nichtstatisch deklarierten Felder sowie Referenzen zu anderen Objekten. Mehrere Referenzen zu einem Objekt werden mit einem Mechanismus zum Referenz-Sharing geschrieben, so dass Objektgraphen wieder reproduziert werden können. Als Beispiel werden Instanzen der Klassen java.awt.Button und java.io.FileOutputStream erzeugt. Die zweite Instanz wird als buch.ser bezeichnet und dazu benutzt, um eine Instanz der Klasse java.io.ObjectOutputStream zu erzeugen. Im Anschluss wird die Methode writeObject() aufgerufen, um das Button-Objekt abzuspeichern. Die Methode flush() wird zum Schluss dazu eingesetzt, um den gesamten Stream in die gewünschte Datei zu schreiben:
// Beispiel SchreibeApplet.java
// Speichern eines Buttons in der Datei buch.ser
import java.awt.*;
import java.applet.*;
import java.io.*;
public class SchreibeApplet extends Applet {
java.awt.Button button1;
public void init(){
setLayout(null);
setSize(426,162);
button1 = new java.awt.Button();
button1.setLabel("OpenJava");
button1.setBounds(24,48,156,40);
button1.setBackground(new Color(12632256));
add(button1);
try{
FileOutputStream fos = new FileOutputStream("buch.ser");
ObjectOutputStream oos = new ObjectOutputStream(fos);
oos.writeObject(button1);
oos.flush();
} catch (Exception e) {
System.out.println("Exception: " + e);
}
}
}
Für das oben dargestellte Beispiel soll nun eine Lesemethode geschrieben werden, damit die in der Datei buch.ser enthaltenen Daten wieder hergestellt werden können. Hierzu wird eine Instanz der Klasse java.io.FileInputStream erzeugt und dazu benutzt, um eine Instanz der Klasse java.io.ObjectInputStream zu erzeugen. Die Methode readObject() wird anschließend aufgerufen, um das Button-Objekt einzulesen. Diese Methode liefert ein Objekt zurück, das in den Button-Typ umgewandelt wird (Casting), um das Button-Objekt wieder herstellen zu können.
// Beispiel restoreApplet.java
// Wiederherstellung der oben gespeicherten Daten
import java.awt.*;
import java.applet.*;
import java.io.*;
public class restoreApplet extends Applet {
public void init() {
setLayout(null);
setSize(426,266);
try {
FileInputStream fis = new FileInputStream("buch.ser");
ObjectInputStream oos = new ObjectInputStream(fis);
Button b = (Button)oos.readObject();
add(b);
} catch (Exception e) {
System.out.println("Exception: " + e);
}
}
}
Die Serialisierung von Klassen bedeutet im Normalfall keinen großen Aufwand. Eine zu serialisierende Klasse muss lediglich eines der zwei folgenden Interfaces implementieren: Entweder das Interface java.io.Serializable oder das Interface java.io.Externalizable. Es sei hier darauf aufmerksam gemacht, dass beim Testen der oben genannten Beispiele Security-Exceptions auftreten können. Man sollte daher den Appletviewer mit den entsprechenden Sicherheitseinstellungen benutzen.
Interface Serializable
Das Interface Serializable beinhaltet keine Methoden, die implementiert werden müssen. Aufgabe des Interfaces ist es, die Daten der Klasse automatisch zu speichern bzw. wieder herzustellen. Das Interface beinhaltet lediglich ein Feld, SerialVersionUID (hierzu siehe Kapitel 9.7).
Interface Externalizable
Soll exakt festgelegt werden, welche Objekte abzuspeichern sind, so reicht das Interface Serializable nicht aus. Ein Bean muss dann das Interface Externalizable implementieren. Diese Schnittstelle erlaubt es dem Programmierer, festzulegen, welche Daten gespeichert werden. Hierzu müssen die folgenden zwei Methoden implementiert werden:
Diese zwei Methoden erlauben ein beliebiges Abspeichern der Formate sowie der Daten der JavaBeans-Komponente. Beide erzeugen dann eine IOException
Versionshaltung
Bei der Speicherung eines Objekts in Java mit Hilfe des Interfaces Serialization werden die Dateninhalte, der Objekttyp und eine Versionsidentifikation in der .ser Datei gespeichert. Die Versionsidentifikation liegt in Form einer 64 bit langen Zeichenkette vor, die als Prüfsumme (Hash-Code) erzeugt wird. Sie enthält Informationen über die Klassenstruktur und deren Inhalt, über den Klassennamen, nichtstatische oder transiente Datenfelder und Methoden. Diese Information wird als Stream Unique IDentifier (SUID) bezeichnet. Jede Änderung der Struktur eines Beans resultiert folglich in einer neuen SUID, wodurch Kompatibilitätsprobleme entstehen können. Um die SUID eines Beans abzufragen, wird die folgende Syntax verwendet:
serialver -show
Nach der Eingabe dieser Anweisung erscheint eine grafische Oberfläche, in der der Klassenname eingegeben werden muss. Als Resultat wird anschließend die SUID einer Klasse ausgegeben. In Abb. 9-15 ist die Oberfläche dargestellt, die beim Aufruf von serialver -show und bei der Angabe des gewünschten Klassennamens, der in diesem Fall die oben genannte Klasse SchreibeApplet ist, erscheint.
Abb. 9.15: Introspektion der Information „Serial Version"
Änderungen einer Klasse können hierbei zu großen Problemen führen. So kann es vorkommen, dass eine Klasse eine Datei lesen will, die aber in einer früheren Version geschrieben wurde. Dies kann zu einem Kompatibilitätsproblem führen. Im JDK sind einige Mechanismen aufgeführt, die diesbezügliche Änderungen zulassen. JavaBeans-Programmierer dürfen dementsprechend lediglich neu definierte Instanzvariablen und Interfaces einfügen, nicht aber existierenden Code-Fragmente ändern. Wenn bspw. die Variable preis, die im Beispiel MyBean1.java verwendet wurde, geändert und dementsprechend die Lese- und Schreibmethoden von int auf float geändert werden sollen und verhindert werden soll, dass der Datentyp umgesetzt wird, dann muss eine neue Variable des gewünschten Datentyps deklariert werden, anstatt die Variable umzuschreiben. Die Klasse enthält dann die folgenden Variablen mit den entsprechenden Methoden:
import java.awt.*;
import java.beans.*;
public class myBean1 {
//...
private int preis = 2;
private float preis2 = 2f;
public int getPreis() {
return preis;
}
public float getPreis() {
return preis2;
}
}
Diese Vorgehensweise garantiert, dass die neue Version des Beans mit serialisierten Dateien arbeiten kann, die auf einer alten Version basieren. Zusammengefasst weist der Serialisierungsmechanismus die folgenden Eigenschaften auf:
Beans und Java-Archive Java-Archive wurden in JDK 1.1 eingeführt. Auf Binärebene entsprechen sie ZIP-Archiven. Das
Die BeanBox (siehe Kapitel 9.8) bietet im File-Menü die Option an, ein ausgetestetes Bean sofort als JAR-Archiv abzuspeichern. In dieser Datei werden neben den Klassen bspw. auch Meta-Informationen gespeichert, die vom BDK erstellt worden sind. Im Verzeichnis der JAR-Datei wird zusätzlich eine HTML-Datei gespeichert, die den direkten Aufruf des Beans mit Hilfe des Appletviewers oder eines Browsers unterstützt.
Um aus einer Java-Klasse ein Bean zu erzeugen, muss eine Archivdatei erstellt werden. Diese Datei wird wie auch bei anderen Java-Anwendungen mit dem Befehl jar erzeugt. Auf den Befehl folgen der Name des Archivs, der Name einer Manifest-Datei und die Dateien, die zum Bean gehören.
jar {ctx} {vfm0M} [JAR-Datei] [manifest-Datei] dateien
JAR benutzt zwei Kategorien von Optionen. Die Elemente der ersten Kategorie (c, t, und x) sind nicht kombinierbar, d. h. nur ein Element dieser Kategorie darf benutzt werden. Die Elemente der zweiten Kategorie (v, f, m, 0 und M) sind sowohl mit den Elementen der ersten Kategorie als auch untereinander kombinierbar. Die Beschreibung dieser Optionen findet sich in Tab. 9-4.
|
Option |
Bedeutung |
|
c |
Erzeugen einer neuen Archivdatei. |
|
t |
Anzeige des Inhalts einer JAR-Datei. |
|
x |
Extraktion der angegebenen Dateien aus dem Archiv. Wenn keine Datei explizit angegeben ist, werden alle Dateien extrahiert. |
|
v |
Generiert ausführliche Ausgabeinformationen. |
|
f |
Spezifiziert den Dateinamen des Archivs. |
|
m |
Fügt Informationen aus der angegebenen Manifest-Datei an ein bestehendes Archiv an. |
|
0 |
Null Kompression. |
|
M |
Es wird keine Manifest-Datei für das Archiv erzeugt. |
