[Java] Einfache Objektserialisierung ( Speichern + Laden )

Termi · 6. Mai 2012

Moin,
ein kleines Beispiel wie man Daten einfach speichern und laden kann.
Falls ihr Fragen habt könnt ihr mich gerne fragen.

Code:

Java

public static void main(String[] args) throws Exception {
String meinString = "StageTwo";
int meinInt = 1337;
System.out.println("Mein String vor dem Speichern: " + meinString);
System.out.println("Mein int vor dem Speichern: " + meinInt);
// Speichern
FileOutputStream fos = new FileOutputStream("savedata.dat");
ObjectOutputStream oos = new ObjectOutputStream(fos);
oos.writeObject(meinString);
oos.writeObject(meinInt);
oos.close();
fos.close();
// Zurücksetzen
meinString = null;
meinInt = 0;
System.out.println("Mein String: " + meinString);
System.out.println("Mein int: " + meinInt);
// Laden
FileInputStream fis = new FileInputStream("savedata.dat");
ObjectInputStream ois = new ObjectInputStream(fis);
meinString = (String)ois.readObject();
meinInt = (Integer)ois.readObject();
ois.close();
fis.close();
System.out.println("Mein String nach dem Speichern: " + meinString);
System.out.println("Mein int nach dem Speichern: " + meinInt);
}

Alles anzeigen

Ausgabe:

Code

Mein String vor dem Speichern: StageTwo
Mein int vor dem Speichern: 1337
Mein String: null
Mein int: 0
Mein String nach dem Speichern: StageTwo
Mein int nach dem Speichern: 1337

dongdong · 6. Mai 2012

Du solltest den Writer nach den write calls noch flushen
Und man sollte dazu sagen, dass ein Objekt Serializable implementieren muss, damit es via Serialisierung gespeichert werden kann.

Akeshihiro · 6. Mai 2012

dongdong Irgendwie stehst du auf das flush Man braucht da nix flushen. flush ist nur interessant, wenn es gepufferte Streams sind, aber selbst dann in den meisten Fällen auch nicht wirklich, denn close führt vor dem Schließen ebenfalls ein flush aus.

Termi · 6. Mai 2012

dongdong schrieb:

Und man sollte dazu sagen, dass ein Objekt Serializable implementieren muss, damit es via Serialisierung gespeichert werden kann.

Deswegen auch das "Einfache" :D.

dongdong · 6. Mai 2012

Akeshihiro schrieb:

dongdong Irgendwie stehst du auf das flush Man braucht da nix flushen. flush ist nur interessant, wenn es gepufferte Streams sind, aber selbst dann in den meisten Fällen auch nicht wirklich, denn close führt vor dem Schließen ebenfalls ein flush aus.

Dann legt man eben nen BufferedOutputStream drüber :P.
Sicher das close, automatisch flushed? Wusste ich nicht. Ich sags nur gern, weil ich in nem Programm mal vergessen hab zu flushen und mich gewundert hab warum in meiner Textdatei später die Hälfte fehlte

Akeshihiro · 6. Mai 2012

Ja, bin mir sicher Aber eben auch immer brav closen Das fällt aber seit Java 7 mit try-resource sowieso flach, was wohl eingeführt wurde, weil wohl eine große Menge an Leuten den Umgang mit Streams und Co. nicht richtig hinbekommen hat.

Das mit dem BufferedOutputStream würde nichts bringen, da dann die writeXXX-Methoden nicht mehr zugreifbar sind, weil der ObjectStream dann gekapselt ist.

dongdong · 6. Mai 2012

Ne ich hab das so gemeint mit dem BufferedOutputStream:

Code

ObjectOutputStream oos = new ObjectOutputStream(new BufferedOutputStream(new FileOutputStream("test.txt")));

Hab auch gerade in der Source vom JDK nachgesehen, wird tatsächlich vorher geflushed.

Wer vorher den Stream ned geclosed hat, wird jetzt auch kein try-resource verwenden. Vermut ich mal

Akeshihiro · 6. Mai 2012

Zitat

Wer vorher den Stream ned geclosed hat, wird jetzt auch kein try-resource verwenden. Vermut ich mal

Vermute ich auch mal, aber noch einfacher kann man es nun wirklich nicht mehr machen. Irgendwo ist auch Schluss mit lustig. Die Programmiersprachen der 4. Generation machen es einem schon wirklich einfach, da sie auf einem sehr hohen Abstraktionslevel sind und vor allem mit all den Frameworks, die es dem Programmierer echt leicht machen und ihn vor dem ganzen low-level-Kram bewahren. Leider führt das auch immer mehr dazu, dass immer mehr Leute das Programmieren nicht wirklich ernst nehmen, da das bereits Grundschüler bis zu einem gewissen Level machen könnten und sich somit auch eben solche dummen Fehler einschleichen.

Also stimmt schon, wer sich vorher keine Gedanken um ein sauberes Handling gekümmert hat, der wird es auch im Nachhinein nicht tun.

Übrigens, was das Snippet angeht. Wenn man Objekte serialisiert, dann sollte man bei eigenen Objekten auch wirklich aufpassen, dass man immer bei einer Änderung an der Klasse auch die serialVersionUID neu generieren lässt oder zumindest inkrementiert oder wie auch immer man das handhaben möchte. Jedenfalls sollte sich die Version ändern, vor allem, wenn der Eingriff größer war. Damit lassen sich dann alte Objekte nicht mehr laden, aber man bekommt einen entsprechenden Fehler, der einen darauf aufmerksam macht, dass die serialVersionUID nicht passt. Das ist wichtig! Ein Kollege hat das nämlich vor Kurzem nicht gemacht und wir konnten mit einem Tool die alten serialisierten Dateien nicht laden und das lag eben daran, dass er an der Klasse Veränderungen vorgenommen hatte, aber eben nicht die serialVersionUID neu generiert und somit bekamen wir nur die Meldung, dass die Datei nicht geladen werden konnte. Wir fanden erst nach etwa einem halben Tag dann durch das SVN raus, dass an der Klasse rumgebastelt wurde und kamen dem so auf die Spur.

Teilen